EF Core 10 adds native left joins, named query filters, JSON columns and vector search

EF Core 10, covered in a recent dev.to overview, is more than the usual round of small quality-of-life fixes. According to the author, this release lands several changes that retire long-standing workarounds: hand-assembled left joins, an all-or-nothing global query filter system, and the need for an external engine to do similarity search. The walkthrough demonstrates the features against a small blog, book and author model running on .NET 10 and SQL Server.

Left and right joins become real operators

Until now, writing a left join in LINQ-to-Entities meant chaining GroupJoin, SelectMany and DefaultIfEmpty — a pattern the dev.to author describes as something nobody remembers from one use to the next. EF Core 10 introduces LeftJoin and RightJoin as first-class query operators that take the joined set, key selectors for both sides and a result selector in a single call. According to the overview, the generated SQL is identical to what the old pattern produced, but the code is shorter and reads like the join the developer intended. The author calls this the change most people will use most often.

Query filters can be named and toggled individually

Global query filters, used for patterns such as soft deletes, multi-tenancy or showing only verified rows, previously allowed one filter per entity. The bigger limitation: IgnoreQueryFilters disabled every filter at once, so an entity carrying both a soft-delete filter and a tenant filter could not turn off one while keeping the other.

EF Core 10 fixes this by letting each filter carry a name at configuration time. IgnoreQueryFilters then accepts a list of filter names, so an admin screen that must display soft-deleted rows while still respecting tenant isolation becomes a one-line change instead of a manual re-implementation of the surviving filter, according to the dev.to write-up.

Complex types stored as JSON

Complex types can now be persisted as a JSON document in a single column via a ToJson mapping. In the walkthrough, a BookAttributes object — genre, page count, language and an array of tags — lives in one nvarchar column, yet remains queryable in LINQ: a predicate on the page count translates to SQL JSON path access. The author positions this as a sensible option for attribute bags that vary between records and are not worth their own dedicated table.

Vector similarity search, built in

The flashiest addition targets retrieval-augmented generation scenarios. SQL Server 2025 introduces a native vector type, and EF Core 10 can map columns to it and translate distance functions: ordering by EF.Functions.VectorDistance with a cosine metric produces a nearest-neighbour query directly through the context. Paired with Microsoft.Extensions.AI to generate embeddings — the demo uses an Azure OpenAI embedding model — the retrieval half of a RAG pipeline becomes an ordinary EF Core query with no separate vector database in the stack.

Smaller changes and upgrade caveats

The overview also notes that ExecuteUpdateAsync keeps gaining expressive power, including updates driven by other columns, allowing more bulk updates to skip loading entities entirely. A batch of closed LINQ translation gaps and improved SQL for existing queries arrives simply by upgrading.

The author flags several pitfalls: the vector type requires SQL Server 2025 or a recent Azure SQL tier; migrating existing single filters means naming them and updating every IgnoreQueryFilters call site, or behaviour changes; JSON-mapped columns query fine but filtering performance on large tables depends on the database's JSON indexing support; and the right side of a LeftJoin result can be null when no match exists, so projections should handle that defensively.

Why it matters

EF Core 10 removes friction that .NET developers have worked around for years. LeftJoin and RightJoin eliminate boilerplate from one of the most common query shapes in business applications, and named filters resolve a genuine architectural headache for anyone combining soft deletes with multi-tenancy. The JSON mapping gives teams a pragmatic option between rigid relational schemas and untyped blobs. Most significantly, built-in vector search means .NET shops building RAG features can keep their data — and their similarity queries — inside SQL Server rather than operating an additional vector store, consolidating infrastructure that has been drifting apart.