LINQ looks clean and harmless in C#.
But in real backend APIs, small mistakes can quietly turn into serious performance issues.
Here are 3 I’ve seen (and made) while working with .NET and Entity Framework:
1. Loading entire tables into memory
A common mistake is doing this:
var orders = dbContext.Orders.ToList();
var recent = orders.Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7));
This pulls everything into memory first, then filters in C#.
The problem:
- unnecessary memory usage
- slow processing on large datasets
- wasted database optimization
Fix:
Let the database do the work:
var recent = dbContext.Orders
.Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7))
.ToList();
2. Hidden multiple database calls
LINQ queries can be deceptively reused:
var query = dbContext.Orders.Where(o => o.Total > 100);
var count = query.Count();
var list = query.ToList();
This can result in multiple database executions depending on how it's used.
Fix:
Materialize once:
var list = dbContext.Orders
.Where(o => o.Total > 100)
.ToList();
var count = list.Count;
3. Fetching more data than needed
Another common issue:
var orders = dbContext.Orders.ToList();
var result = orders.Select(o => new
{
o.Id,
o.CustomerName
});
You are still loading full rows from the database even though you only need 2 fields.
Fix:
Project early:
var result = dbContext.Orders
.Select(o => new
{
o.Id,
o.CustomerName
})
.ToList();
Key idea
LINQ itself is not the problem.
The real issue is where the execution happens:
- in memory
- or in the database
In backend systems, that difference matters a lot.
Closing thought
Most performance issues in APIs are not “big architecture problems”.
They start with small LINQ decisions like these.