EF Core 11 Can Change the SQL Behind a LINQ Query I Never Touched. That’s What I Check Before Upgrading.

Removed CASTs, pruned joins, MaxBy and FullJoin: how I compare generated SQL, baselines, and query plans when the ORM changes underneath me.

Albatros

8 min read

·

3 hours ago

--

Listen

Share

When I use Entity Framework Core, I mostly don’t think about how the query I write reaches the database. I write code like this, get the result, and move on:

English isn’t my first language, so I used AI to help translate, organize, and write the English sentences in this piece. The experiences and opinions are my own.

var users = await context.Users
    .Where(x => x.Name.StartsWith("A"))
    .ToListAsync();

In day-to-day development, that convenience matters. But the database doesn’t run this C# code. EF Core and the provider I use translate the query into SQL, and the database builds an execution plan for that SQL.

So when I change the EF Core version, the command sent to the database can change even if I never touch my LINQ query.

That’s what caught my attention most in EF Core 11’s new features. Support for things like FullJoin, MaxByAsync, and MinByAsync is nice. But the removal of unnecessary joins, orderings, and conversions in existing queries may affect the code I use every day more directly.