What's New in EF Core 10: Features Every .NET Developer Should Adopt in 2026
EF Core 10 — the data access layer that ships alongside .NET 10 as a Long Term Support release — introduces a set of changes that genuinely simplify day-to-day LINQ and schema work without requiring a rewrite of your existing code. This guide walks through what actually changed, what the migration impact looks like, and which features are worth adopting immediately versus which ones need more maturity in your environment.
🎁 Want implementation-ready .NET source code you can drop straight into your project? Join Coding Droplets on Patreon for exclusive tutorials, premium code samples, and early access to new content. 👉 https://www.patreon.com/CodingDroplets
💻 Full source code available on GitHub: EF Core 10 New Features Demo
Because EF Core 10 is an LTS release (supported until November 2028), it is the version teams should standardise on when upgrading from EF Core 8 or earlier. Unlike preview-only cycles, the features below are production-stable.
Why EF Core 10 New Features Matter for Production Teams
The EF Core team rarely ships headline features without at least a preview cycle, which means most items in EF Core 10 have been battle-tested through .NET 10 previews. The result is a release with higher confidence than a standard non-LTS increment.
Three broad themes run through EF Core 10's improvements:
- LINQ ergonomics — long-requested operators and API improvements that eliminate verbose workarounds
- SQL Server 2025 and Azure SQL alignment — native support for the new
jsonandvectorcolumn types - Precision improvements — sharper query filters, better aggregate translation, and ExecuteUpdate / ExecuteDelete enhancements
Each of these maps directly to common pain points that enterprise teams raise in ADO.NET and EF Core upgrade conversations.
First-Class LeftJoin and RightJoin in LINQ
What Is the Problem LeftJoin Solves?
For over a decade, writing a LEFT OUTER JOIN in LINQ required a cumbersome combination of GroupJoin, SelectMany, and DefaultIfEmpty. The pattern was correct but verbose enough that developers often fell back to raw SQL or Dapper for join-heavy queries.
EF Core 10 adds LeftJoin and RightJoin as first-class LINQ operators in .NET 10, and the EF Core provider translates them to the expected SQL LEFT JOIN and RIGHT JOIN clauses.
The practical impact is that left-join queries — used in every application that has optional foreign-key relationships — become readable and maintainable by developers at all seniority levels on the team. The generated SQL remains identical to what a hand-written query would produce, so there is no performance regression.
What to Adopt Now vs Later: Adopt immediately. The translation is stable, and the ergonomic improvement is significant. Teams upgrading from EF Core 8 should plan a pass to replace GroupJoin patterns.
Native JSON Column Type Support on SQL Server 2025 and Azure SQL
SQL Server 2025 and Azure SQL introduce a dedicated json data type, replacing the previous pattern of storing JSON in nvarchar columns. EF Core 10 maps this type automatically when you configure your context with UseAzureSql or set a compatibility level of 170 or higher.
How EF Core 10 Handles the JSON Type
If your application already stores JSON via nvarchar columns and you enable compatibility level 170, EF Core migration tooling will generate migrations that change those columns from nvarchar(max) to json. Primitive collections and complex types marked with .ToJson() will also default to the new type.
LINQ queries over JSON-mapped properties produce efficient SQL using the JSON_VALUE() function with the RETURNING clause, enabling SQL Server to use native JSON indexing rather than string parsing.
What to Adopt Now vs Later: Teams running on SQL Server 2025 or Azure SQL should evaluate this carefully. The schema migration from nvarchar to json is additive from SQL Server's perspective, but it requires EF Core migrations and a deployment window. For teams still on SQL Server 2022 or earlier, this feature is not applicable yet.
Vector Search Support Leaves Experimental Status
In EF Core 9, vector similarity search was marked experimental. EF Core 10 promotes it to production-ready, with improvements to how owned reference entities handle the SqlVector<float> type.
Why Vector Search in the ORM Matters
Retrieval-augmented generation (RAG) pipelines and semantic search features require storing embeddings alongside business entities. Without ORM support, teams typically resorted to raw SQL or a separate vector database. EF Core 10's vector support lets you store embeddings in SQL Server 2025's vector column type and query them using cosine, dot product, or Euclidean distance — all from LINQ.
The capability is tightly coupled to SQL Server 2025 and Azure SQL, which carry the underlying VECTOR_DISTANCE() function. Teams not yet on those platforms cannot use this feature, but they should be aware it exists for when they do upgrade.
What to Adopt Now vs Later: Early adopters building AI-augmented search should plan for this. Stable teams on older SQL Server versions should note it for future planning but do not need to act now.
ExecuteUpdateAsync Gets Delegate-Based Setters
What Changed in ExecuteUpdate
ExecuteUpdate and ExecuteUpdateAsync were introduced in EF Core 7 to allow bulk updates without loading entities into memory. In early versions, the setter expressions required a direct property assignment pattern that could become awkward when update logic was computed or passed in from higher layers.
EF Core 10 allows delegate-based setters in ExecuteUpdateAsync, which means the update logic can be expressed in a way that is more natural to pass as a parameter, store in a variable, or reuse across queries. The generated SQL bulk update behaviour does not change; only the API surface improves.
For teams with complex auditing or multi-column bulk update operations, this removes a class of workarounds that previously required either raw SQL or multiple tracked-entity cycles.
What to Adopt Now vs Later: If your team actively uses ExecuteUpdate, this is a simple quality-of-life improvement worth adopting in the next feature cycle.
Named Query Filters
What Are Named Query Filters?
Global query filters in EF Core let you apply a WHERE clause to all queries for a given entity type — the canonical use case is soft-delete filtering. In EF Core 9 and earlier, you could define at most one filter per entity type, and disabling it required calling IgnoreQueryFilters(), which removed all filters at once.
EF Core 10 introduces named query filters. You can register multiple independent filters per entity type, each with a distinct name, and selectively disable them using IgnoreQueryFilters("filterName"). This makes multi-tenancy scenarios significantly cleaner: a tenant isolation filter and a soft-delete filter can coexist and be toggled independently.
What to Adopt Now vs Later: Any team using global query filters for more than one concern should adopt named filters as part of their EF Core 10 upgrade. The improvement directly addresses a common architectural limitation.
Aggregate Function Improvements
EF Core 10 extends LINQ-to-SQL translation for aggregate functions. Several operations that previously fell back to client-side evaluation — or required raw SQL — now translate to server-side aggregates. The relevant improvements touch GroupBy queries with complex projections and numeric aggregates over nullable value types.
Client-side evaluation fallback is a common silent performance issue: EF Core fetches all rows and then applies the aggregation in application memory rather than in the database. If this has been affecting any of your reports or statistics queries, EF Core 10's improved translation can reduce data transfer and improve latency without changing your LINQ code.
What to Adopt Now vs Later: Audit your queries using EF Core logging or a tool like MiniProfiler after upgrading. Look for any remaining LINQ translation warnings in the logs. If aggregation queries were falling back, they may now translate correctly.
What Does Migration from EF Core 8 Look Like?
For teams upgrading from EF Core 8 (the previous LTS), the path to EF Core 10 is straightforward at the package level. The API surface is largely compatible, and breaking changes in the release are focused on edge cases rather than core query operations.
The primary areas to validate before upgrading in production:
- GroupJoin patterns — these still work but you now have a simpler alternative
- Global query filter usage — review any
IgnoreQueryFilters()calls; they continue to work but named filter adoption is worth planning - JSON column migration — only relevant if you are targeting SQL Server 2025; requires explicit migration generation
For teams skipping EF Core 9 (non-LTS), be aware that EF Core 9 introduced several breaking changes in how certain LINQ expressions are translated. EF Core 10 maintains those translations, so an upgrade path of 8 → 10 will encounter the EF9 breaking changes even if you skip the 9 release.
The official EF Core 10 migration guide on Microsoft Learn is the authoritative reference for breaking changes and is updated as patches ship.
What to Adopt Now vs Later: Quick Summary
| Feature | Recommendation |
| LeftJoin / RightJoin operators | Adopt now — replace GroupJoin workarounds |
| JSON native column type | Adopt when on SQL Server 2025 / Azure SQL |
| Vector search | Adopt for AI features on SQL Server 2025 |
| ExecuteUpdateAsync delegate setters | Adopt in next bulk-update refactor |
| Named query filters | Adopt now — especially with multi-tenancy |
| Aggregate translation improvements | Validate after upgrade; passive improvement |
☕ Prefer a one-time tip? Buy us a coffee — every bit helps keep the content coming!
Frequently Asked Questions
Is EF Core 10 a Long Term Support release?
Yes. EF Core 10 is an LTS release supported until November 2028. Teams that skipped EF Core 9 (STS) should upgrade directly from EF Core 8 to EF Core 10 to land on a supported, stable version.
Do LeftJoin and RightJoin work with all EF Core providers?
The LINQ operators are part of .NET 10 and are provider-agnostic at the API level, but the SQL translation depends on each database provider implementing support. The SQL Server, SQLite, and PostgreSQL (Npgsql) providers all support them in EF Core 10. Check your provider's release notes if you use a less common database.
Does adopting EF Core 10's named query filters require any schema changes?
No. Named query filters are a runtime query-composition feature and have no schema impact. There are no migrations to run and no database changes involved. You update how filters are registered in OnModelCreating and how they are disabled in individual queries.
Will my existing global query filters break when I upgrade to EF Core 10?
No. Unnamed global query filters continue to work exactly as they did. EF Core 10 adds the named filter API as an additive enhancement. The existing IgnoreQueryFilters() method (with no arguments) still disables all filters on a query.
Is the JSON column type migration in EF Core 10 automatic or do I need to opt in?
It is opt-in via database compatibility level. EF Core does not silently migrate your nvarchar JSON columns. When you run dotnet ef migrations add after configuring UseAzureSql or setting compatibility level 170, EF Core will generate a migration that changes the column type. Review that migration before applying it to production.
How do I confirm my EF Core queries are now translating to server-side SQL instead of client-side evaluation?
Enable EF Core's query logging at the Information level and look for Translating query expression or warnings about client-side evaluation. You can also use SQL Server Extended Events, EF Core interceptors, or a profiling tool like MiniProfiler to inspect the SQL being generated for your queries after the upgrade.
Can I use EF Core 10's vector search feature without SQL Server 2025?
No. Vector search in EF Core 10 requires the vector data type and VECTOR_DISTANCE() function, both of which are only available in SQL Server 2025 and Azure SQL. If you need vector similarity search on earlier SQL Server versions, you will need a separate vector store or a custom extension.
