Slow EF Core queries are rarely EF Core's fault. Most of the time it's a missing projection, an accidental N+1, or change tracking doing work nobody asked for.
This page maps EF Core performance techniques from quick wins to specialized optimizations. Start with query optimization; that's where the biggest gains hide.
Why EF Core Performance Matters
Entity Framework Core is the most popular ORM in the .NET ecosystem. It makes data access simple, but that simplicity can hide inefficient queries, excessive database round trips, and memory issues.
Without proper optimization, EF Core can become the bottleneck in your application - especially under load.
This guide collects the most impactful performance techniques, organized from quick wins to advanced strategies.
Query Optimization
The biggest performance gains usually come from how you write your queries. These articles cover techniques that reduce database load and improve response times.
- How to Improve Performance with EF Core Query Splitting
- Unleash EF Core Performance with Compiled Queries
- How I Made My EF Core Query Faster with Batching
- How to Use Global Query Filters in EF Core
- DbContext Is Not Thread Safe: Parallelizing EF Core Queries the Right Way
- Common EF Core Query Performance Mistakes
- Solving the N+1 Query Problem in EF Core
- Lazy, Eager, and Explicit Loading in EF Core
Choosing Your Data Access
EF Core is not the only way to talk to your database, and it is not always the fastest. These guides help you pick the right tool and get the most out of a lightweight one.
Bulk Operations
When you need to insert or update thousands of rows, the standard SaveChanges() approach won't cut it. These articles show you how to handle bulk data efficiently.
- Fast SQL Bulk Inserts with C# and EF Core
- What You Need to Know About EF Core Bulk Updates
- How to Use the New Bulk Update Feature in EF Core 7
- Optimizing Bulk Database Updates in .NET
Concurrency and Locking
Concurrent access to the same data can cause race conditions and data corruption. EF Core provides built-in mechanisms to handle this safely.
- Solving Race Conditions with EF Core Optimistic Locking
- A Clever Way to Implement Pessimistic Locking in EF Core
- Working with Transactions in EF Core
Advanced Features
EF Core has a rich feature set beyond basic CRUD. These articles cover interceptors, raw SQL, soft deletes, multi-tenancy, and more.
- 5 EF Core Features You Need to Know
- How to Use EF Core Interceptors
- EF Core Raw SQL Queries
- Implementing Soft Delete with EF Core
- Multi-Tenant Applications with EF Core
- Using Multiple EF Core DbContext in a Single Application
- Using Stored Procedures and Functions with EF Core and PostgreSQL
- EF Core Compiled Models for Faster Startup
- DbContext Pooling in EF Core
- EF Core Connection Resiliency
- Understanding the EF Core Change Tracker
What's New in EF Core 10
EF Core 10 ships with .NET 10 and adds features that used to require workarounds. These articles cover what changed and how to put it to use.
- Named Query Filters in EF 10: Multiple Query Filters Per Entity
- What's New in EF Core 10: LeftJoin and RightJoin Operators in LINQ
Migrations and Schema Management
Keeping your database schema in sync with your code is a critical part of any EF Core project.
- EF Core Migrations: A Detailed Guide
- EF Core Migrations Best Practices
- Zero-Downtime EF Core Migrations
Frequently Asked Questions
What should I optimize first in an EF Core application?
Start by logging the generated SQL and measuring the slow query in the database. Fix N+1 round trips, project only required columns, add indexes for selective predicates, and remove tracking from read-only entity queries before considering lower-level optimizations.
Should every read query use AsNoTracking?
Use AsNoTracking for entity queries that will not be updated through that DbContext. A DTO projection is often better for API reads because it selects only required columns and does not materialize tracked entities in the first place.
Is AsSplitQuery always faster than one joined query?
No. Split queries avoid cartesian duplication when loading several collections, but they add database round trips and may observe changes between statements. Inspect the generated SQL and measure both shapes for the actual graph.
When do compiled EF Core queries help?
They help on hot paths where repeated LINQ compilation is measurable compared with cheap database work. They rarely matter when network and database execution dominate, so benchmark before adding the extra query definition.
