Co nowego w EF Core 9: funkcje, które musisz znać

Entity Framework Core 9 shipped alongside .NET 9 in November 2024, and after spending a solid amount of time working with it across several projects, I can say it’s one of the most meaningful releases in a while. Not because it reinvents the wheel, but because it polishes the areas where EF Core has historically caused the most friction — query translation, performance, and working with modern data patterns.

In this post, I’ll walk through the features that have had the biggest impact on my day-to-day work. If you’re still on EF Core 8 (or even 7), this should give you a clear picture of what’s waiting for you on the other side of the upgrade.

EF Core 9 in the .NET 9 Ecosystem

EF Core 9 targets .NET 8 and .NET 9, which means you don’t necessarily need to upgrade your entire application to .NET 9 to take advantage of most of these features. That said, some of the AOT and performance improvements are tightly coupled with .NET 9 runtime changes, so you’ll get the most out of it by going all the way.

The release follows the odd/even cadence Microsoft has established: odd-numbered releases (like .NET 9) are Standard Term Support (STS) with 18 months of support, while even releases (like .NET 8) are Long Term Support (LTS). Keep this in mind when planning your upgrade timeline.

LINQ Translation Improvements

This is where most developers will feel the difference immediately. EF Core 9 has made significant strides in translating LINQ expressions to SQL that actually makes sense.

Better GroupBy Translations

If you’ve ever written a GroupBy query in EF Core and ended up with client-side evaluation warnings or bizarre SQL, you know the pain. EF Core 9 handles a much broader set of GroupBy scenarios directly in SQL.

var salesByCategory = await context.Products
    .GroupBy(p => p.Category.Name)
    .Select(g => new
    {
        Category = g.Key,
        TotalRevenue = g.Sum(p => p.Price * p.UnitsSold),
        AveragePrice = g.Average(p => p.Price),
        ProductCount = g.Count()
    })
    .OrderByDescending(x => x.TotalRevenue)
    .ToListAsync();

In previous versions, queries involving aggregations over navigation properties inside GroupBy would sometimes fall back to client evaluation. EF Core 9 translates this cleanly to a single SQL query with GROUP BY, SUM, AVG, and COUNT.

Complex Projections and Subqueries

Nested subqueries and complex projections also got a serious upgrade. Consider something like this:

var orderSummaries = await context.Customers
    .Select(c => new CustomerSummaryDto
    {
        Name = c.FullName,
        TotalOrders = c.Orders.Count(),
        MostRecentOrder = c.Orders
            .OrderByDescending(o => o.OrderDate)
            .Select(o => new OrderBriefDto
            {
                Id = o.Id,
                Date = o.OrderDate,
                Total = o.LineItems.Sum(li => li.Quantity * li.UnitPrice)
            })
            .FirstOrDefault(),
        TopCategory = c.Orders
            .SelectMany(o => o.LineItems)
            .GroupBy(li => li.Product.Category.Name)
            .OrderByDescending(g => g.Count())
            .Select(g => g.Key)
            .FirstOrDefault()
    })
    .ToListAsync();

EF Core 9 can now translate this entire expression into SQL without triggering client-side evaluation. The generated query uses correlated subqueries and lateral joins where appropriate, and the SQL plan is considerably more efficient than what earlier versions would produce.

Parameterized Primitive Collections

One of the standout LINQ improvements is the ability to pass collections of primitive values directly into queries:

var statusFilter = new List<string> { "Active", "Pending", "Review" };

var filteredOrders = await context.Orders
    .Where(o => statusFilter.Contains(o.Status))
    .ToListAsync();

In EF Core 8, this was translated using IN clauses with inlined values, which meant the query plan cache couldn’t be reused when the list changed. EF Core 9 parameterizes these collections properly, sending them as a structured parameter. This is a big deal for query plan caching on SQL Server and PostgreSQL.

Bulk Operations — ExecuteUpdate and ExecuteDelete

ExecuteUpdate and ExecuteDelete were introduced in EF Core 7, but EF Core 9 expands what you can do with them in meaningful ways.

More Complex Update Expressions

You can now use more complex expressions in ExecuteUpdate, including references to other tables through navigation properties:

await context.Products
    .Where(p => p.Category.IsDiscontinued)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(p => p.IsAvailable, false)
        .SetProperty(p => p.DiscontinuedDate, DateTimeOffset.UtcNow)
        .SetProperty(p => p.Price, p => p.Price * 0.5m));

This generates a single UPDATE statement with a JOIN to the categories table — no need to load entities into memory, no change tracking overhead.

Conditional Bulk Deletes with Subqueries

Bulk deletes with subquery filters are now fully supported:

await context.AuditLogs
    .Where(log => log.CreatedAt < DateTime.UtcNow.AddYears(-2))
    .Where(log => !context.ProtectedRecords
        .Any(pr => pr.AuditLogId == log.Id))
    .ExecuteDeleteAsync();

This translates to a DELETE with a NOT EXISTS subquery, exactly what you’d write by hand. No entities loaded, no round trips.

JSON Column Enhancements

JSON columns have been one of the most exciting features in recent EF Core releases, and EF Core 9 takes them further.

Querying Inside JSON

You can now filter and project data from within JSON columns with better translation support:

public class Order
{
    public int Id { get; set; }
    public string CustomerName { get; set; }
    public ShippingAddress Address { get; set; } // Stored as JSON
    public List<OrderNote> Notes { get; set; }   // Stored as JSON
}

public class ShippingAddress
{
    public string Street { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string ZipCode { get; set; }
    public string Country { get; set; }
}

public class OrderNote
{
    public DateTime CreatedAt { get; set; }
    public string Text { get; set; }
    public string Author { get; set; }
}

Configuration in your DbContext:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Order>(builder =>
    {
        builder.OwnsOne(o => o.Address, ab =>
        {
            ab.ToJson();
        });

        builder.OwnsMany(o => o.Notes, nb =>
        {
            nb.ToJson();
        });
    });
}

Now you can query directly into JSON:

var newYorkOrders = await context.Orders
    .Where(o => o.Address.State == "NY")
    .OrderByDescending(o => o.Notes.Count)
    .Select(o => new
    {
        o.CustomerName,
        o.Address.City,
        LatestNote = o.Notes
            .OrderByDescending(n => n.CreatedAt)
            .Select(n => n.Text)
            .FirstOrDefault()
    })
    .ToListAsync();

EF Core 9 generates proper JSON_VALUE and JSON_QUERY calls on SQL Server (or equivalent on other providers), and the translation covers a much wider range of LINQ operations on JSON elements than before.

Updating JSON Properties

One of the friction points in EF Core 8 was that updating a single property inside a JSON column would cause the entire JSON document to be rewritten. EF Core 9 improves this with more granular change tracking for JSON-mapped types, generating more targeted updates when possible.

var order = await context.Orders.FindAsync(orderId);
order.Address.ZipCode = "10001";
await context.SaveChangesAsync();

On supported providers, this can generate a more targeted JSON modification rather than rewriting the whole blob.

Complex Types — Value Objects Without Identity

Complex types are one of the features that Domain-Driven Design practitioners have been waiting for. Unlike owned types, complex types have no identity — they’re pure value objects.

[ComplexType]
public record Money(decimal Amount, string Currency);

[ComplexType]
public record DateRange(DateTime Start, DateTime End);

public class Project
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Money Budget { get; set; }
    public DateRange Timeline { get; set; }
}

These get stored as flattened columns in the parent table — Budget_Amount, Budget_Currency, Timeline_Start, Timeline_End — without requiring a separate table or any kind of key.

The key difference from owned types: complex types are compared by value, not by reference. Two Money instances with the same Amount and Currency are considered equal, regardless of which entity they belong to.

var expensiveProjects = await context.Projects
    .Where(p => p.Budget.Amount > 100_000m && p.Budget.Currency == "USD")
    .OrderByDescending(p => p.Budget.Amount)
    .ToListAsync();

This translates directly to filtering on the flattened columns — clean, efficient, and exactly what you’d expect.

HierarchyId Support for SQL Server

If you’ve ever worked with hierarchical data in SQL Server — organizational charts, category trees, file systems — you know that HierarchyId is the built-in type for this. EF Core 9 brings first-class support for it.

public class Employee
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Title { get; set; }
    public HierarchyId PathFromCeo { get; set; }
}

You can now query hierarchical relationships directly:

var managerId = HierarchyId.Parse("/1/3/");

// All direct and indirect reports
var allReports = await context.Employees
    .Where(e => e.PathFromCeo.IsDescendantOf(managerId))
    .Where(e => e.PathFromCeo != managerId) // exclude the manager
    .OrderBy(e => e.PathFromCeo)
    .ToListAsync();

// Direct reports only (one level down)
var directReports = await context.Employees
    .Where(e => e.PathFromCeo.GetAncestor(1) == managerId)
    .ToListAsync();

// Get an employee's depth in the hierarchy
var employeesWithDepth = await context.Employees
    .Select(e => new
    {
        e.Name,
        e.Title,
        Level = e.PathFromCeo.GetLevel()
    })
    .OrderBy(e => e.Level)
    .ToListAsync();

All of these translate to SQL Server’s native HierarchyId methods. If you’ve been implementing tree structures with self-referencing foreign keys and recursive CTEs, this is a much cleaner approach.

Compiled Models and AOT Support

Performance-conscious developers will appreciate the continued investment in compiled models and ahead-of-time (AOT) compilation support.

Compiled Models

Compiled models pre-generate the model metadata that EF Core normally builds at startup. For large models (think hundreds of entities), this can dramatically reduce cold-start time.

dotnet ef dbcontext optimize --output-dir CompiledModels --namespace MyApp.CompiledModels

Then wire it up:

builder.Services.AddDbContext<AppDbContext>(options =>
    options
        .UseSqlServer(connectionString)
        .UseModel(MyApp.CompiledModels.AppDbContextModel.Instance));

In EF Core 9, compiled models are more complete — they support more mapping features and generate smaller output. For a model with around 400 entities, startup time can drop from several seconds to near-instantaneous.

AOT Compilation Progress

Full Native AOT support for EF Core is still a work in progress, but EF Core 9 makes significant strides. Many of the reflection-heavy code paths have been refactored to be trimming-friendly, and compiled models are a key part of the AOT story. If you’re targeting scenarios like Azure Functions or microservices where cold start matters, these improvements are directly relevant.

Cosmos DB Provider Updates

The Azure Cosmos DB provider continues to mature with EF Core 9. Some notable improvements:

Partition Key Handling

The provider now supports hierarchical partition keys and handles partition key filters more intelligently:

public class TenantDocument
{
    public string Id { get; set; }
    public string TenantId { get; set; }  // Partition key
    public string Region { get; set; }     // Sub-partition key
    public string Content { get; set; }
}

// This query now correctly uses the partition key for routing
var docs = await context.TenantDocuments
    .Where(d => d.TenantId == "tenant-42" && d.Region == "us-east")
    .Where(d => d.Content.Contains("important"))
    .ToListAsync();

Improved LINQ to NoSQL Translation

More LINQ operations now translate to Cosmos DB’s SQL dialect, including better support for Contains, Any, nested array operations, and mathematical functions. Queries that previously fell back to client evaluation are now handled server-side.

Vector Search Support

EF Core 9 introduces early support for vector similarity search with Cosmos DB, which is useful if you’re building applications that integrate with embeddings or AI-driven search:

var results = await context.Documents
    .OrderBy(d => EF.Functions.VectorDistance(d.Embedding, queryVector))
    .Take(10)
    .ToListAsync();

Migration Improvements

Migrations got some quality-of-life improvements that make working with them less painful in team environments.

Temporal Tables in Migrations

Migrations now handle temporal table configuration more gracefully, with proper support for period columns and history table naming:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Employee>()
        .ToTable("Employees", b => b.IsTemporal(t =>
        {
            t.HasPeriodStart("ValidFrom");
            t.HasPeriodEnd("ValidTo");
            t.UseHistoryTable("EmployeeHistory");
        }));
}

Idempotent Scripts

The Script-Migration command (and its CLI equivalent) produces better idempotent scripts by default, with improved handling of edge cases around schema changes that depend on data existing in certain states.

Migration Bundles

Migration bundles, which package your migrations into a standalone executable for deployment, are more reliable in EF Core 9 with better error reporting and retry logic for transient failures.

dotnet ef migrations bundle --self-contained -r linux-x64

This produces a binary you can run in your CI/CD pipeline without needing the .NET SDK installed on your deployment target.

Performance Benchmarks

Here are some rough benchmarks from my own testing. These are from a project with roughly 200 entities, running against SQL Server 2022, measured with BenchmarkDotNet. Your numbers will vary, but the relative improvements should be similar.

The compiled model improvement is the most dramatic, but the steady improvements across the board add up — especially in high-throughput scenarios where you’re executing thousands of queries per second.

Upgrading from EF Core 8

If you’re on EF Core 8, the upgrade path is relatively smooth. Here’s a checklist:

1. Update your packages:

<PackageReference Include="Microsoft.EntityFrameworkCore" Version="9.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="9.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="9.0.0" />

2. Check for breaking changes. The list for EF Core 9 is relatively short compared to some previous releases. The most notable ones:

• Some previously obsolete APIs have been removed
• Changes in how certain GroupBy queries are translated (they now go server-side, which changes behavior if you were relying on client evaluation)
• Minor changes in migration scaffolding output

3. Re-generate compiled models if you’re using them. The format changed, so old compiled models won’t work with EF Core 9.

4. Run your test suite. Pay special attention to queries that were previously evaluated on the client — they might now be evaluated on the server, which is usually better but could surface data differences.

5. Check your Cosmos DB queries if you’re using that provider. The improved translations mean some queries will execute differently (usually faster), but it’s worth verifying the results are identical.

A minimal upgrade for a typical project looks like this:

dotnet add package Microsoft.EntityFrameworkCore --version 9.0.0
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 9.0.0
dotnet add package Microsoft.EntityFrameworkCore.Design --version 9.0.0
dotnet build
dotnet test

If everything compiles and tests pass, you’re probably in good shape. If you hit issues, the EF Core 9 breaking changes documentation has detailed migration guidance for each change.

Wrapping Up

EF Core 9 isn’t a revolutionary release — it’s an evolutionary one, and that’s exactly what it needed to be. The LINQ improvements alone justify the upgrade for most projects, and features like JSON column enhancements, complex types, and HierarchyId support open up patterns that were previously awkward or impossible.

If I had to pick the three features that have had the most impact on my projects:

1. Parameterized primitive collections — because query plan cache efficiency matters at scale
2. JSON column improvements — because the hybrid relational-document pattern is incredibly useful
3. Compiled models — because startup time directly affects developer productivity and deployment speed

The EF Core team has been on a solid trajectory since EF Core 5, and version 9 continues that trend. If you’re already on EF Core 8, the upgrade is low-risk and high-reward. If you’re on something older, there’s never been a better time to make the jump.

Happy coding — and happy querying.