Cloud Parts

Entity Framework Core

Microsoft’s object-relational mapper for .NET: you query C# classes with LINQ, a DbContext tracks the entities it loads, and SaveChanges writes every change back as SQL through a pluggable database provider.

What it is
Object-relational mapping (full orms)
Type
Open source
Made by
Microsoft (.NET Foundation)
License
MIT
Facts checked
8 October 2026

What it is

An EF Core model is a set of entity classes plus a context class derived from DbContext, with a DbSet<T> property per table. You can write the classes first and let EF Migrations create and evolve the database, or generate the model from an existing database. Queries are LINQ expressions (db.Blogs.Where(b => b.Rating > 3).ToListAsync()) that the provider translates to SQL. Every entity a query returns, or that you Add or Attach, is tracked by the context’s change tracker; SaveChanges turns the tracked changes into INSERT, UPDATE and DELETE statements. A DbContext is meant to be a short-lived unit of work: create it, load, change, save, dispose.

Related data is loaded eagerly with Include, explicitly, or lazily through an optional proxies package or an injected loader. Microsoft’s performance guide recommends avoiding lazy loading because it makes the N+1 problem easy to trigger. When LINQ can’t express a query, FromSql starts a query from raw SQL. Databases plug in as providers: Microsoft ships SQL Server and Azure SQL, SQLite and Azure Cosmos DB, while PostgreSQL (Npgsql), MySQL and MariaDB (Pomelo, or Oracle’s own) and others come from third parties. EF Core is released with each .NET version: EF Core 10, a long-term support release from November 2025, is supported until November 2028, and EF Core 11 is planned for November 2026.

Why teams pick it

  • LINQ queries checked by the C# compiler, translated to readable SQL
  • Change tracking and SaveChanges give a unit of work for free in short-lived contexts
  • Migrations, scaffolding from an existing database and a provider model covering SQL Server, SQLite, Cosmos DB, PostgreSQL, MySQL and more
  • Shipped and supported by Microsoft on the .NET release cadence, with long-term support releases

Watch out for

  • LINQ hides the SQL: an innocent-looking query can produce a slow plan or N+1 round trips unless you log and check the generated SQL
  • Lazy loading is opt-in but, once on, makes the N+1 problem easy to trigger
  • Provider quality varies: PostgreSQL and MySQL support comes from third-party projects with their own release timing
  • Not every EF6 feature came over: the graphical model designer and EDMX files are not planned, and updating a model from a changed database is still on the backlog

Alternatives

What all full orms have in common →

How it fits with other technologies

Load blogs with their posts in one query, change one, and save · csharp

using Microsoft.EntityFrameworkCore;

await using var db = new BloggingContext();   // a DbContext with DbSet<Blog> Blogs

// Include loads the posts with the blogs instead of one query per blog later
var blogs = await db.Blogs
    .Include(b => b.Posts)
    .Where(b => b.Rating > 3)
    .ToListAsync();

blogs[0].Url = "https://example.com/new";   // the change tracker notices
await db.SaveChangesAsync();                 // one UPDATE for the changed row

See it in a real stack

No architecture uses Entity Framework Core yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2008–2025

Microsoft’s first object-relational mapper for .NET was the ADO.NET Entity Framework, shipped with .NET Framework 3.5 Service Pack 1 and Visual Studio 2008 SP1 on 11 August 2008. It was widely criticised: a “vote of no confidence” from developers experienced with entity-based architectures gathered at least a thousand signatures. Version 4.0 in 2010 answered many of the complaints, 4.1 in 2011 added Code First, and Entity Framework 6 in 2013 became open source under the Apache License.

When Microsoft rebuilt .NET as a cross-platform, modular runtime, it rewrote the ORM too. The new version was first called Entity Framework 7; in January 2016 Microsoft renamed it Entity Framework Core 1.0, alongside .NET Core 1.0 and ASP.NET Core 1.0, because it was a new product rather than an upgrade. EF Core 1.0 shipped on 27 June 2016 as a “lightweight, extensible, and cross-platform version of Entity Framework”, without every EF6 feature.

Since then EF Core has shipped with each .NET release and caught up on most of EF6: lazy loading in 2.1, table-per-type inheritance and many-to-many without a join class in 5.0, table-per-concrete-type and custom conventions in 7.0. EF6 is still supported but no longer actively developed.

Why it’s built this way

A rewrite instead of porting EF6
EF6 was built for the Windows-only .NET Framework. A lightweight, extensible core that ran on .NET Core across platforms meant starting again, and accepting that some EF6 features would arrive late or never.
Providers as plug-ins
A provider model let SQLite, PostgreSQL, MySQL, Cosmos DB and other teams ship support themselves instead of waiting for Microsoft to build each one.
Short-lived contexts as the unit of work
Each DbContext tracks the entities it loaded and writes their changes at SaveChanges, so a web request maps naturally to one context and one transaction.
Lazy loading opt-in
EF Core 1.0 shipped without lazy loading. Version 2.1 added the building blocks plus an optional proxies package, and Microsoft still recommends eager or explicit loading because they make each database round trip visible in the code.

Timeline

  1. 2008

    Entity Framework 1 ships with .NET Framework 3.5 SP1

  2. 2013

    Entity Framework 6 is released as open source

  3. 2016

    EF7 is renamed EF Core 1.0 in January; 1.0 ships on 27 June

  4. 2018

    EF Core 2.1 adds lazy loading

  5. 2020

    EF Core 5.0 adds table-per-type inheritance and many-to-many

  6. 2025

    EF Core 10 ships in November as a long-term support release

Sources9 · facts checked 8 October 2026

Improve this page on GitHub