Have you ever written a LINQ query that worked perfectly in C#, but when you checked the SQL it generated, you wondered—how on earth did it get to *that*? In this session, you’ll learn three things in particular: how expression trees control translation, how caching shapes performance and memory use, and what to watch for when null logic doesn’t behave as expected. If you’ve suspected there’s black-box magic inside Entity Framework Core, the truth is closer to architecture than magic. EF Core uses a layered query pipeline that handles parsing, translation, caching, and materialization behind the scenes. First we’ll look at how your LINQ becomes an expression tree, then the provider’s role, caching, null semantics, and finally SQL and materialization. And it all starts right at the beginning: what actually happens the moment you run a LINQ query.

From LINQ to Expression Trees

When you write a LINQ query, the code isn’t automatically fluent in SQL. LINQ is just C#—it doesn’t know anything about databases or tables. So when you add something like a `Where` or a `Select`, you’re really calling methods in C#, not issuing commands to SQL. The job of Entity Framework Core is to capture those calls into a form it can analyze, before making any decisions about translation or execution. That capture happens through expression trees. Instead of immediately hitting the database, EF Core records your query as a tree of objects that describe each part. A `Where` clause doesn’t mean “filter rows” yet—it becomes a node in the tree that says “here’s a method call, here’s the property being compared, and here’s the constant value.” At this stage, nothing has executed. EF is simply documenting intent in a structured form it can later walk through. One way to think about it is structure before meaning. Just like breaking a sentence into subject and verb before attempting a translation, EF builds a tree where joins, filters, projections, and ordering are represented as nodes. Only once this structure exists can SQL translation even begin. EF Core depends on expression trees as its primary mechanism to inspect LINQ queries before deciding how to handle them. Each clause you write—whether a join or a filter—adds new nodes to that object model. For example, a condition like `c.City == "Paris"` becomes a branch with left and right parts: one pointing to the `City` property, and one pointing to the constant string `"Paris"`. By walking this structure, EF can figure out what parts of your query map to SQL and what parts don’t. Behind the scenes, these trees are not abstract concepts, but actual objects in memory. Each node represents a method call, a property, or a constant value—pieces EF can inspect and categorize. This design gives EF a reliable way to parse your query without executing it yet. Internally, EF treats the tree as a model, deciding which constructs it can send to SQL and which ones it must handle in memory. This difference explains why some queries behave one way in LINQ to Objects but fail in EF. Imagine you drop a custom helper function inside a lambda filter. In memory, LINQ just runs it. But with EF, the expression tree now contains a node referring to your custom method, and EF has no SQL equivalent for that method. At that point, you’ll often notice a runtime error, a warning, or SQL falling back to client-side evaluation. That’s usually the signal that something in your query isn’t translatable. The important thing to understand is that EF isn’t “running your code” when you write it. It’s diagramming it into this object tree. And if a part of that tree doesn’t correspond to a known SQL pattern, EF either stops or decides to push that part of the work into memory, which can be costly. Performance issues often show up here—queries that seem harmless in C# suddenly lead to thousands of rows being pulled client-side because EF couldn’t translate one small piece. That’s why expression trees matter to developers working with EF. They aren’t just an internal detail—they are the roadmap EF uses before SQL even enters the picture. Every LINQ query is first turned into this structural plan that EF studies carefully. Whether a query succeeds, fails, or slows down often depends on what that plan looks like. But there’s still one more step in the process. Once EF has that expression tree, it can’t just ship it off to the database—it needs a gatekeeper. Something has to decide whether each part of the tree is “SQL-legal” or something that should never leave C#. And that’s where the next stage comes in.

The Gatekeeper: EF Core’s Query Provider

Not every query you write in C# is destined to become SQL. There’s a checkpoint in the middle of the pipeline, and its role is to decide what moves forward and what gets blocked. This checkpoint is implemented by EF Core’s query provider component, which evaluates whether the expression tree’s nodes can be mapped to SQL or need to be handled in memory. You can picture the provider like a bouncer at a club. Everyone can show up in line, but only the queries dressed in SQL-compatible patterns actually get inside. The rest either get turned away or get redirected for client-side handling. It’s not about being picky or arbitrary. The provider is enforcing the limits of translation. LINQ can represent far more than relational databases will ever understand. EF Core has to walk the expression tree and ask of each node: is this something SQL can handle, or is it something .NET alone can execute? That call gets made early, before SQL generation starts, which is why you sometimes see runtime errors up front instead of confusing results later. For the developer, the surprise often comes from uneven support. Many constructs map cleanly—`Where`, `Select`, `OrderBy` usually translate with no issue. Others are more complicated. For example, `GroupBy` can be more difficult to translate, and depending on the provider and the scenario, it may either fail outright or produce SQL that isn’t very efficient. Developers see this often enough that it’s a known caution point, though the exact behavior depends on the provider’s translation rules. The key thing the provider is doing here is pattern matching. It isn’t inventing SQL on the fly in some magical way. Instead, it compares the expression tree against a library of translation patterns it understands. Recognized shapes in the tree map to SQL templates. Unrecognized ones either get deferred to client-side execution or rejected. That’s why some complex queries work fine, while others lead to messages about unsupported translation. The decision is deterministic—it’s all about whether a given pattern has a known, valid SQL output. This is also the stage where client-side evaluation shows up. If a part of the query can’t be turned into SQL, EF Core may still run it in memory after fetching the data. At first glance, that seems practical. SQL gives you the data, .NET finishes the job. But the cost can be huge. If the database hands over thousands or even millions of rows just so .NET can filter them afterward, performance collapses. Something that looked innocent in a local test database can stall badly in production when the data volume grows. Developers often underestimate this shift. Think of a query that seems perfectly fine while developing against a dataset of a few hundred rows. In production, the same query retrieves tens of thousands of records and runs a slow operation on the application server. That’s when users start complaining that everything feels stuck. The provider’s guardrails matter here, and in many cases it’s safer to get an error than to let EF try to do something inefficient. For anyone building with EF, the practical takeaway is simple: always test queries against real or representative data, and pay attention to whether performance suddenly nosedives in production. If it feels fast locally but drags under load, that’s often a sign the provider has pushed part of your logic to client-side evaluation. It’s not automatically wrong, but it is a signal you need to pay closer attention. So while the provider is the gatekeeper, it isn’t just standing guard—it’s protecting both correctness and performance. By filtering what can be translated into SQL and controlling when to fall back to client-side execution, it keeps your pipeline predictable. At the same time, it’s under constant pressure to make these decisions quickly, without rewriting your query structure from scratch every time. And that’s where another piece of EF Core’s design becomes essential: a system to remember and reuse decisions, rather than starting from zero on every request.

Caching: EF’s Secret Performance Weapon

Here’s where performance stops being theoretical. Entity Framework Core relies on caching as one of its biggest performance tools, and without it, query translation would be painfully inefficient. Every LINQ query starts its life as an expression tree and has to be analyzed, validated, and prepared for SQL translation. That work isn’t free. If EF had to repeat it from scratch on every execution, even simple queries would bog down once repeated frequently. To picture what that would mean in practice, think about running the same query thousands of times per second in a production app. Without caching, EF Core would grind through full parsing and translation on each call. The database wouldn’t necessarily be the problem—your CPU would spike just from EF redoing the prep work. This is why caching isn’t an optional optimization; it’s the foundation that makes EF Core workable at real-world scale. So how does it actually help? EF Core uses caching to recognize when a query shape it has already processed shows up again. Instead of re-analyzing the expression tree node by node, EF can reuse the earlier work. That means when you filter by something like `CustomerId`, the first run takes longer while EF figures out how to map that filte