In this blog, I am going to recap and explain with code the 8 most common mistakes developers make with EF Core when working with relational schemas. These anti-patterns negatively affect application performance and are often the bottleneck for application robustness.

1. N + 1 Problem​

The list starts with one of the worst situations that can happen — the N + 1 issue. Imagine you query specific orders, and each order can have one or many products. An N + 1 query might look like the following:

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .ToList();

foreach (var manufacturer in manufacturers)
{
    Console.WriteLine("Manufacturer: " + manufacturer.Name);

    // loading all products for each manufacturer explicitly
    context.Entry(manufacturer).Collection(m => m.Products).Load();
    foreach (var product in manufacturer.Products)
    {
        Console.WriteLine(product.Title);
    }
}

Or, if you are using lazy loading, the query you compose may look even more innocent:

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .ToList();

foreach (var manufacturer in manufacturers)
{
    Console.WriteLine("Manufacturer: " + manufacturer.Name);

    foreach (var product in manufacturer.Products)
    {
        Console.WriteLine("\t" + product.Title);
    }
}

In my sample database, I have "Apple" and "Tesla" as the only manufacturers in the US, so since we get 2 parent entities, an ORM will generate 3 queries in total. Both the explicit and lazy loading queries produce the same queries below, combined with the WriteLine output:

SELECT [m].[Id], [m].[Country], [m].[Name]
FROM [Manufacturers] AS [m]
WHERE [m].[Country] = N'USA'

Manufacturer: Apple

SELECT [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title]
FROM [Products] AS [p]
WHERE [p].[ManufacturerId] = @p

    iPhone 17
    iPad mini 7

Manufacturer: Tesla

SELECT [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title]
FROM [Products] AS [p]
WHERE [p].[ManufacturerId] = @p

    Model 3
    Cybertruck

I only had 2 parent entities in my example, but you can already imagine how easily this could scale to more manufacturers, generating even more queries. A solution proposed was to use Eager Loading.

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    // eagerly load all products
    .Include(m => m.Products)
    .ToList();

foreach (var manufacturer in manufacturers)
{
    Console.WriteLine("Manufacturer: " + manufacturer.Name);

    foreach (var product in manufacturer.Products)
    {
        Console.WriteLine("\t" + product.Title);
    }
}

SELECT [m].[Id], [m].[Country], [m].[Name], [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title]
FROM [Manufacturers] AS [m]
LEFT JOIN [Products] AS [p] ON [m].[Id] = [p].[ManufacturerId]
WHERE [m].[Country] = N'USA'
ORDER BY [m].[Id]

Manufacturer: Apple
    iPhone 17
    iPad mini 7
Manufacturer: Tesla
    Model 3
    Cybertruck

As we can see, this time, only one query was generated and all the related entities, which are products in this case, were loaded immediately. The Include() method generates a JOIN statement, which needs to be used cautiously or otherwise can lead to an anti-pattern number two.

We will also come back to this query later when we discuss Projection.

2. Cartesian Explosion​

As mentioned previously, when we load a related entity with eager loading, EF Core is using a JOIN statement, hence logically, two or more Include calls that load collection navigations on one entity cause a Cartesian product.

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .Include(m => m.Products)
    .Include(m => m.Suppliers)
    .ToList();

SELECT [m].[Id], [m].[Country], [m].[Name], [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title], [s0].[ManufacturersId], [s0].[SuppliersId], [s0].[Id], [s0].[Name]
      FROM [Manufacturers] AS [m]
      LEFT JOIN [Products] AS [p] ON [m].[Id] = [p].[ManufacturerId]
      LEFT JOIN (
          SELECT [m0].[ManufacturersId], [m0].[SuppliersId], [s].[Id], [s].[Name]
          FROM [ManufacturerSupplier] AS [m0]
          INNER JOIN [Suppliers] AS [s] ON [m0].[SuppliersId] = [s].[Id]
      ) AS [s0] ON [m].[Id] = [s0].[ManufacturersId]
      WHERE [m].[Country] = N'USA'
      ORDER BY [m].[Id], [p].[Id], [s0].[ManufacturersId], [s0].[SuppliersId]

The generated SQL query is a clear sign of Cartesian explosion. For example, if a manufacturer has 6 products and 3 suppliers, 6 x 3 = 18 rows will be sent over the network. If we used three joins, we would need to multiply the result count of each entity, so the total rows returned would explode — and that's where the issue gets its name: Cartesian Explosion.

EF Core proposes another approach, to use AsSplitQuery() method, which will generate a separate roundtrip query for each Include() method.

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .Include(m => m.Products)
    .Include(m => m.Suppliers)
    .AsSplitQuery()
    .ToList();

SELECT [m].[Id], [m].[Country], [m].[Name]
FROM [Manufacturers] AS [m]
WHERE [m].[Country] = N'USA'
ORDER BY [m].[Id]

SELECT [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title], [m].[Id]
FROM [Manufacturers] AS [m]
INNER JOIN [Products] AS [p] ON [m].[Id] = [p].[ManufacturerId]
WHERE [m].[Country] = N'USA'
ORDER BY [m].[Id]

SELECT [s0].[ManufacturersId], [s0].[SuppliersId], [s0].[Id], [s0].[Name], [m].[Id]
FROM [Manufacturers] AS [m]
INNER JOIN (
    SELECT [m0].[ManufacturersId], [m0].[SuppliersId], [s].[Id], [s].[Name]
    FROM [ManufacturerSupplier] AS [m0]
    INNER JOIN [Suppliers] AS [s] ON [m0].[SuppliersId] = [s].[Id]
) AS [s0] ON [m].[Id] = [s0].[ManufacturersId]
WHERE [m].[Country] = N'USA'
ORDER BY [m].[Id]

As we can see here, first a query to get all the filtered manufacturers was used, then two different queries were used, one to get related Products and another one to get related Suppliers. The query to get related suppliers uses two joins because it is a many-to-many relationship, but the overall concept is that we got rid of the problem with Cartesian products.

However, this approach has its own flaws, and that's why it is not the default behavior.

optionsBuilder.UseSqlServer(
    connectionStringBuilder.ConnectionString,
    options => options.UseQuerySplittingBehavior(QuerySplittingBehavior.SplitQuery));

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .Include(m => m.Products)
    .Include(m => m.Suppliers)
    .AsSingleQuery()
    .ToList();

The reason why the split query is not the default behavior is that it creates the following issues:

• Results are not guaranteed to be consistent. Within a single query, database engines guarantee consistency; however, if the underlying data changes between your split queries, the final result may be inconsistent. It is possible to specify a transaction manually and use a stronger isolation level such as serializable, but this would impact performance and lock your database.

• Multiple roundtrips are sent to the database. Network calls are often the underlying reason for slow responses, so multiple network calls can also degrade performance.

So in the end, both approaches have downsides. For that reason, it is sometimes worth thinking about your queries before you start designing your schema. If you frequently need to load an entity together with its related collections, a document database (such as Azure Cosmos DB or MongoDB) may be a better fit. There, the related data is usually embedded directly inside the parent document, typically stored as JSON, so a single read returns everything at once and neither a Cartesian explosion nor extra roundtrips come into play.

3. Requesting more rows than needed.​

The first two anti-patterns were not particularly specific to EF Core, but rather just how relational databases work. This anti-pattern is rather EF Core and C# expression trees specific.

Not everything we put into our query building process can be translated into SQL statements, for example consider the following snippet:

var manufacturers = context.Manufacturers
    .Where(m => IsAmericanManufacturer(m))
    .ToList();

Unhandled exception. System.InvalidOperationException: The LINQ expression 'DbSet<Manufacturer>()
    .Where(m => Program.IsAmericanManufacturer(m))' could not be translated.
    
Either rewrite the query in a form that can be translated, or switch to client evaluation explicitly...

It's not really "the database" that has a problem with IsAmericanManufacturer — it's EF Core's LINQ-to-SQL translation layer that can't turn an arbitrary C# method into a SQL fragment. It's also worth noting when this actually throws: writing .Where(m => IsAmericanManufacturer(m)) alone doesn't throw anything, it just builds an expression tree. The exception only fires once the query is executed, i.e. once you call .ToList(), .FirstOrDefault(), or otherwise enumerate it.

What is interesting, is that in the past, this was not the default design the EF Core development team chose. In early versions of EF Core, this would implicitly translate this query into a client-side query, meaning for this case, all the rows would be returned from the database, and then filtering would happen inside the dotnet executable. EF Core 3 removed that automatic fallback and made it throw an exception instead, precisely to stop this anti-pattern from happening silently.

That said, you can still reintroduce the exact same problem today — EF Core just requires you to opt into it. If you "fix" the exception above by inserting AsEnumerable() before the Where(), you're telling EF Core to stop translating the query at that point and fall back to plain LINQ-to-Objects for everything after it:

var manufacturers = context.Manufacturers
    .AsEnumerable() // switches to LINQ-to-Objects from here on
    .Where(m => IsAmericanManufacturer(m))
    .ToList();

AsEnumerable() itself doesn't trigger a database call — it's just a compile-time switch from IQueryable to IEnumerable, the actual round-trip still only happens once .ToList() runs. But because the filter now lives after that switch, EF Core has nothing left to put in a WHERE clause, so the entire Manufacturers table gets pulled over the network before any filtering happens:

SELECT [m].[Id], [m].[Country], [m].[Name]
FROM [Manufacturers] AS [m]

This is the anti-pattern this section is named after: requesting, and transferring, more rows than the application actually needs, then throwing most of them away in memory.

Obviously, the takeaway from this anti-pattern is to try to always maximize filtering on the database level and keep network calls as light as possible, unless your application has an intended need for client-side filtering or pagination, like a grid component, for example.

4. Not using projection​

It's fairly common for an entity to contain more data (or columns, in this context) than a particular method or API client actually needs. For this reason, it's more efficient to avoid requesting all of an entity's data and use projection instead. Going back to the first code snippet, we can use a projection to get back only the product titles.

var productTitles = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .SelectMany(m => m.Products.Select(p => p.Title))
    .ToList();


foreach (var productTitle in productTitles)
{
    Console.WriteLine(productTitle);
}

SELECT [p].[Title]
FROM [Manufacturers] AS [m]
INNER JOIN [Products] AS [p] ON [m].[Id] = [p].[ManufacturerId]
WHERE [m].[Country] = N'USA'

iPhone 17
iPad mini 7
Model 3
Cybertruck

With this projection, only one column is returned in the result set, making the query more efficient. It's also worth noting that with projection, we don't need to explicitly load related entities — they're loaded automatically as part of the same query.

An important point to note here, though, is that EF Core's change tracker only tracks entities that come back from a query as the full entity type. Our projection returns plain strings, not Manufacturer or Product instances, so there's nothing for EF Core to track. That means we can't just modify productTitles in memory and call SaveChanges() to persist the change — there's no tracked entity for EF Core to compare against. For this situation, we can use the ExecuteUpdate method (added in EF Core 7), which is called directly on the query — not on an already-projected result — and translates straight into a SQL UPDATE statement without loading or tracking any entities. It runs immediately and skips SaveChanges() entirely, giving us the best of both worlds: an efficient read and an efficient update.

5. Missing pagination or not using keyset pagination​

Normally, we do not want to return all the data, and instead return it in the form of "pages". For instance, say the page size is 20 items, and we need page 3. A query of this type would look like this:

var page = 3;
var pageSize = 20;
var toSkip = (page - 1) * pageSize;
var products = context.Products.OrderBy(p => p.Id)
    .Skip(toSkip)
    .Take(pageSize)
    .ToList();

SELECT [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title]
FROM [Products] AS [p]
ORDER BY [p].[Id]
OFFSET @p ROWS FETCH NEXT @p1 ROWS ONLY

This type of pagination is called Offset pagination. It's called this way because it normally requires an OFFSET keyword to be used. This approach, however, has two main drawbacks:

• Inefficiency — the database engine has to scan through and discard many records, making this pagination more and more inefficient as the skip amount grows.

• Inconsistency — if you showed a user page 2, and in the meantime one record was deleted, later when requesting the page 3, the user would not see one record, because OFFSET would skip it (given, of course, that the deleted record was either in page 1 or page 2).

For this reason, a much better approach is to use a Keyset pagination.

This approach substitutes the Skip method with the Where method. A keyset pagination may look like this:

var lastIdShown = 72;
var pageSize = 20;
var products = context.Products.OrderBy(p => p.Id)
    .Where(p => p.Id > lastIdShown)
    .Take(pageSize)
    .ToList();

SELECT TOP(@p) [p].[Id], [p].[Description], [p].[ManufacturerId], [p].[Price], [p].[Title]
FROM [Products] AS [p]
WHERE [p].[Id] > @lastIdShown
ORDER BY [p].[Id]

This implementation solves both issues. The query becomes resistant to any concurrent changes, and the database engine no longer has to scan through and discard rows to reach the requested page.

The only change in implementation is that now you need to know the last record the user saw, instead of the page number they are requesting.

One trade-off worth knowing, though: because there's no offset to compute from, keyset pagination can't jump straight to an arbitrary page — you can only move to the next (or previous) batch relative to a known cursor.

From the online documentation shared in the live demo, this approach can be used to support both jumping to an arbitrary page and efficient cursor-like advancements.

If random access pagination is necessary, a robust implementation could use keyset pagination when navigating to the next/previous page, and offset navigation when jumping to any other page.

— Microsoft EF Core documentation

6. Not using Async methods​

This is a very straightforward and simple anti-pattern. It means using asynchronous methods in EF Core instead of their synchronous counterparts. For example, prefer ToListAsync() over ToList(), prefer SaveChangesAsync() over SaveChanges(), etc.

cosmosContext.SaveChanges();

System.InvalidOperationException: An error was generated for warning 'Microsoft.EntityFrameworkCore.Database.SyncNotSupported':
 Azure Cosmos DB does not support synchronous I/O. Make sure to use and correctly await only 
 async methods when using Entity Framework Core to access Azure Cosmos DB.

7. Tracking read-only results​

When we query a database, by default EF Core tracks the returned entities, unless certain rules around custom projections apply — which, as we saw in anti-pattern 4, is why projected results aren't tracked in the first place. Tracking means that for every entity returned, EF Core takes a snapshot of its original state and adds it to an internal identity map, so that later, when SaveChanges() is called, it can compare the current values against that snapshot and figure out what actually changed.

That bookkeeping isn't free — it costs extra memory and CPU time. If we're only reading data and have no intention of ever modifying it, for example when returning it straight into an API response, we're paying for a feature we'll never use.

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .ToList();

To avoid this, EF Core lets us opt out of tracking with AsNoTracking():

var manufacturers = context.Manufacturers
    .Where(m => m.Country == Countries.USA)
    .AsNoTracking()
    .ToList();

The SQL generated is exactly the same in both cases — AsNoTracking() doesn't change what's requested from the database, only what EF Core does with the results once they arrive. On read-heavy paths returning a lot of entities, skipping the snapshotting and identity map can meaningfully cut down both memory usage and query time.

If an entire DbContext is only ever used for reads — a dedicated reporting or query context, for instance — it's also possible to make no-tracking the default behavior for every query issued through it, instead of adding AsNoTracking() everywhere:

context.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

8. Not using Indexes​

The final anti-pattern that was brought up touches one of the most popular relational database optimization concepts — using indexes. If you expect to often query by certain columns (or a single column), then consider adding indexes on those columns. The word "often" might be too vague, but think of it as something that is on the hot path or executed regularly. "Query by" here isn't only the WHERE clause — columns you JOIN on or ORDER BY benefit from an index too.

It's worth knowing that EF Core already creates some indexes for you: by convention, it adds an index for every foreign key (and for the columns behind an alternate key). It does not, however, index anything else automatically — regular query columns are still up to you.

On the other hand, data that is only used for a report that runs once a week or once a month generally shouldn't be a candidate for a new index. This is because indexes come with their own cost. They take up extra disk space, since the indexed column values are stored separately, and they slow down writes, because every insert or delete — and every update to an indexed column — now also has to keep the index in sync.

Frequency isn't the only thing to weigh, though. Even on a hot path, an index can be a bad trade if it doesn't help the query planner narrow things down much. A column with very few distinct values — a boolean flag, a status with three options — is a classic example: a query filtering on it still matches a large share of the table, so the database often decides a full scan is cheaper than bouncing between the index and the table, and the index just sits there adding write overhead. Tiny tables fall into the same bucket — if the whole thing fits in a page or two, scanning it is already fast and an index doesn't bring any value.

Summary and recommendations​

This was a written summary — with a few additions of my own — of the .NET Data Community Standup: 8 Real-World Query Anti‑Patterns (and How to Fix Them).

I found it genuinely useful, and that is why I decided to turn it into a blog post. I still encourage you to watch the original video as well — it has no slides, so it works just as well as a podcast if you would rather listen than watch.

I also always enjoy Shay Rojansky's participation and comments in these standups. He is one of my favourite contributors to dotnet, and he has a real talent for explaining things clearly. So if you have time and want to stay sharp, consider watching other stand ups where he participates.

Threads & Processes Overview​

Before diving into code, it is important to have the basics down. When you execute an application, the OS starts a new process, and it is inside this process that threads are created and destroyed.

A thread is essentially a set of instructions that a CPU can process. Normally, one CPU core can process one thread at a time, which might give the impression that computers would be very slow, since most CPUs have only, say, 8 to 16 cores. It is thanks to the thread scheduler that computers can run far more threads than they have cores by rapidly switching between them.

This switching is possible because a CPU executes clock cycles extremely fast — this is what the GHz (gigahertz) measurement stands for, or more technically, clock cycles per second. So a CPU running at 3.2 GHz is capable of running 3 billion 200 million clock cycles per second. Note that this is not the same as how often the CPU switches between threads: a context switch (swapping which thread is running on a core) is a relatively expensive operation handled by the OS, and typically happens on the order of thousands of times per second, not billions.

However, do not be tempted to create thousands of threads in each of your applications and think your application will be faster. Each new thread comes with an extra cost: its own stack, synchronization overhead, and the need for thread-safe code.

Using Threads in C#​

Once the application is started, there is always one main thread that executes the Main method. In typical GUI applications such as Windows Forms, this thread also represents the UI. Hence, if this thread is busy executing a long-running process, the application is not responsive, and users cannot interact with it.

To avoid this issue, we need to delegate longer tasks to another thread and free the main thread as soon as possible. There are several ways a new thread can be created, but in this introductory article we use the Thread class. It is the lowest-level interaction with threads between a process and the OS in the .NET ecosystem, and threads created this way are not managed by the ThreadPool.

var newThread = new Thread(() => {
    // imitate some long-running task, for example a complex pdf generation.
    Thread.Sleep(4000);    
    PrintMessage("Generated PDF");
});

PrintMessage("Before calling a method 'Start'");
newThread.Start();
PrintMessage($"After calling a method 'Start'");


void PrintMessage(string message) => 
    Console.WriteLine($"ThreadId is {Thread.CurrentThread.ManagedThreadId}. {message}");

ThreadId is 1. Before calling a method 'Start'
ThreadId is 1. After calling a method 'Start'
ThreadId is 4. Generated PDF

Process finished with exit code 0.

In the example above, we created a new thread by using the Thread class constructor, which takes a ThreadStart delegate as a parameter. Then, we need to call its Start method to begin execution. The program completes a long-running operation and finishes.

From the output, we can observe that the application's main thread only calls the newThread.Start method, and it is another thread that handles the long-running process.

Thread properties​

You might be wondering: why does the app wait 4 seconds for the non-main thread to complete its task? In other words, why is the process not terminated after the main thread has finished its execution?

Well, it is because an explicitly created thread (using the Thread class constructor) is a non-background (foreground) thread by default, and in .NET, the process keeps running until at least one non-background thread is still executing.

We can verify if the thread is a background thread by using its IsBackground property.

var thread1 = new Thread(() => Console.WriteLine("thread1"));
Console.WriteLine($"thread1 is a background thread: {thread1.IsBackground}");
thread1.Start();

thread1 is a background thread: False
thread1

Process finished with exit code 0.

Additionally, we can set a thread to be a background thread.

var newThread = new Thread(() => {
    // imitate some long-running task, for example a complex pdf generation.
    Thread.Sleep(4000);    
    PrintMessage("Generated PDF");
});

newThread.IsBackground = true;
PrintMessage("Before calling a method 'Start'");
newThread.Start();
PrintMessage($"After calling a method 'Start'");


void PrintMessage(string message) => 
    Console.WriteLine($"ThreadId is {Thread.CurrentThread.ManagedThreadId}. {message}");

ThreadId is 1. Before calling a method 'Start'
ThreadId is 1. After calling a method 'Start'

Process finished with exit code 0.

As we can see, this time the non-main thread was set to be a background thread. Because the main thread (which is the only foreground thread now) finished before a background thread could finish, the process terminated, and since threads live inside a process, the long-running thread terminated as well.

There are several other useful properties we can set on a thread, such as:

• Name — used mostly for debugging purposes.

• Priority — if threads have the same priority, you can never guarantee thread execution order. It is the OS and the thread scheduler that decide the order. However, you can influence it by choosing from five possible priority options.

  • Lowest
  • BelowNormal
  • Normal
  • AboveNormal
  • Highest

  The thread scheduler will prioritize higher-priority threads and try to send them to the CPU for execution before lower-priority ones.

• CurrentCulture — controls culture-sensitive, non-UI operations for the thread, such as number, date, and currency formatting, and string comparison/sorting rules. For example, formatting a DateTime on a thread with CurrentCulture set to en-US produces 8/26/2026, while en-GB produces 26/08/2026.

• CurrentUICulture — determines which language-specific resources (for example, .resx resource files) are loaded via ResourceManager for that thread — in other words, what language your UI text is displayed in. It is independent of CurrentCulture: you could display a UI in French (CurrentUICulture) while still formatting dates and numbers using UK conventions (CurrentCulture).

Other properties of the Thread class do not define setters, these properties are: ThreadState, IsThreadPoolThread, ManagedThreadId which we have already seen, ExecutionContext, and IsAlive.

In upcoming posts, I will explain ExecutionContext and IsThreadPoolThread, as these concepts are substantial enough to deserve their own post.

Summary​

To summarize, operating systems have a thread scheduler that decides which threads get executed on a CPU core and when. Threads only live inside a process (for example, a Google Chrome process), and once a process is terminated, all of its threads are terminated as well.

Creating and managing threads directly with the Thread class, as we did in this article, works, but it is a fairly low-level and manual approach: you are responsible for starting threads, deciding whether they are background or foreground, and coordinating them safely.

For that reason, .NET also provides a higher-level abstraction called Task (in the System.Threading.Tasks namespace), which is commonly used together with async/await to run work without blocking the calling thread. Under the hood, tasks are usually executed on the ThreadPool rather than on dedicated threads you manage yourself. I will cover Task and asynchronous programming in one of the upcoming posts.