The Code Every Developer Has Written and Regretted Most EF Core performance disasters are not exotic edge cases. They get written in the first sprint, look clean in code review, and only reveal themselves when row counts hit production scale. The pattern below has ended more than a few on-call rotations badly: // Looks fine.

We Are .NET

EF Core's naive load-modify-save pattern causes severe performance issues at scale, allocating gigabytes of RAM and issuing one SQL statement per entity. EF Core 7+ introduced ExecuteUpdate and ExecuteDelete, which bypass the change tracker and execute a single server-side SQL statement regardless of row count. Benchmarks against 1M rows show these native methods are ~2-4x faster than the naive approach. For server-side INSERT...SELECT (table-to-table copy without loading entities), EF Core 10 still has no native equivalent — Entity Framework Extensions (EFE) fills this gap with InsertFromQuery, which achieves near-constant memory usage and ~22x speedup at 1M rows. Key caveats include stale tracked entities after batch ops, no interceptor/cascade firing, and the need for explicit transactions when mixing batch ops with SaveChanges.

How to Delete and Update Millions of Rows in EF Core Without Loading a Single Entity - Chris Woody Woodruff

The Code Every Developer Has Written and Regretted

The Built-In Answer: ExecuteUpdate and ExecuteDelete

The Missing Piece: There Is No ExecuteInsert

EFE’s Batch Operations: UpdateFromQuery, DeleteFromQuery, InsertFromQuery