EF Core: the .NET object-database mapper, and what its repository actually tells you

What EF Core is for, and who ends up using it

EF Core is an object-database mapper for .NET. The README describes it as supporting LINQ queries, change tracking, updates and schema migrations, and states that it works with SQL Server, Azure SQL Database, SQLite, Azure Cosmos DB, MariaDB, MySQL, PostgreSQL and other databases through a provider plugin API. The audience follows from that list. If you write C# and you want to read and write rows without hand-writing SQL for every operation, this is the library Microsoft maintains for that job. It is not a micro-ORM and it is not a query builder you drop into an existing ADO.NET call site. It owns the mapping between your classes and your tables, and it expects to own the lifetime of the connection and the unit of work around your changes.

The repository is also home to Microsoft.Data.Sqlite, a lightweight ADO.NET provider for SQLite. The README is explicit that the EF Core provider for SQLite is built on top of that library, and that Microsoft.Data.Sqlite can be used independently or with other data access libraries. That distinction matters when you are choosing a dependency: if you only need parameterised commands and a reader, the Sqlite package is the smaller thing, and EF Core sits above it.

The projects are .NET Foundation projects maintained by Microsoft and licensed under the MIT License, per the README. That combination is the practical reason many teams start here rather than with a smaller ORM: the licence is permissive and the maintainer is not going away.

How change tracking and LINQ become SQL

The mechanism the README demonstrates is a unit of work over a DbContext. You construct a context, call Add on it, and call SaveChanges. Nothing has to be written by hand between those two calls. The context holds the entity, marks it as added, and on SaveChanges issues the insert. Querying goes through a DbSet exposed as a LINQ source: the example orders db.Blogs by BlogId and takes the first result. Updating is assignment plus SaveChanges. Deleting is Remove plus SaveChanges. In all four cases the context is the object that knows what changed since it was loaded.

That is the architecture in miniature. The context tracks entities and their state; the provider translates the LINQ expression tree into the dialect of the target database; migrations compare the model to the database and produce schema operations. The provider plugin API is what makes the same LINQ surface work against SQL Server, SQLite, Cosmos DB and the rest. The expression tree is the reason the translation is not free: every query you write has to be understood by the provider before it becomes SQL, and the shape of the C# you write constrains what the provider can emit.

A consequence worth stating plainly: the SQL is an output, not an input. When a query is slow, you are reading generated SQL and reasoning backwards to the LINQ that produced it. Teams that treat the generated statement as an implementation detail they never look at are the teams that discover the problem in production.

Installing EF Core from NuGet and running a first query

EF Core is distributed on NuGet. The README says to install the provider package corresponding to your target database, and gives three examples. Pick the one that matches your database; installing the base package alone will not connect you to anything.

dotnet add package Microsoft.EntityFrameworkCore.SqlServer

dotnet add package Microsoft.EntityFrameworkCore.Sqlite

dotnet add package Microsoft.EntityFrameworkCore.Cosmos

The README notes that the --version option installs a preview version, pointing at the absoluteLatest package listing. For a first project, the stable package is the sensible default and the preview flag is for tracking unreleased work.

Once a provider is present, the README's basic usage example is the shortest complete loop. It assumes a BloggingContext has already been configured; the README points to the getting started documentation for configuring the DbContext, defining the model and creating the database. The operations below are quoted from that example.

using var db = new BloggingContext();


// Inserting data into the database

db.Add(new Blog { Url = "http://blogs.msdn.com/adonet" });

db.SaveChanges();

After SaveChanges returns, the insert has been sent. The same context then reads back the first blog ordered by BlogId, and the update path assigns a new Url, attaches a new Post through the navigation collection, and calls SaveChanges again. Two SaveChanges calls, two round trips, one tracked graph. That is the behaviour to expect on the first run.

If you would rather not use pre-built packages, the README states that the code can be built and packages created directly on your development machine, linking to docs/getting-and-building-the-code.md. The repository layout supports that: build.sh, build.cmd, restore.sh and test.sh sit at the top level alongside the solution filters. The README also recommends daily builds for getting the latest code and giving feedback, noting that previews and official releases lag significantly behind. That is a real trade-off, not a suggestion to run unreleased code in production.

Where EF Core is the wrong tool

The README does not document rollback, and it does not describe what happens when a migration is applied to a database whose schema has drifted. That silence is the honest starting point for anyone planning schema changes: the documentation linked from the README covers migrations, but the repository README itself gives you no recovery procedure. Treat migration reversibility as something you verify in your own environment rather than something you assume.

Change tracking is the second constraint. It is what makes the four-line insert, query, update, delete loop work, and it is also what you pay for on every read. When you load entities through a tracking context, the context keeps state for them. For read-heavy paths where you never intend to write, that bookkeeping is overhead you did not ask for. The README does not discuss query tracking behaviour at all, so the guidance has to come from the linked documentation, not from this page.

The third case is the one teams hit late. If your workload is a small number of carefully tuned statements against a schema designed by someone else, an object mapper is a layer between you and the thing you actually care about. You will spend time expressing joins as navigations, and then time reading the generated SQL to check it matches what you would have written. The README gives no performance figures and makes no speed claims, so there is no basis here for saying EF Core is fast or slow. What can be said is that the abstraction is real and it is not free.

Finally, provider coverage is a list, not a guarantee. The README names SQL Server, Azure SQL Database, SQLite, Azure Cosmos DB, MariaDB, MySQL and PostgreSQL, and says other databases work through the provider plugin API. If your database is not named, the provider is the thing you check first, and the README links to a providers list in the docs for the rest.

EF Core against Dapper: two different jobs

The comparison people actually search for is EF Core versus Dapper, and the difference is where the mapping lives. Dapper maps a result set to objects and stops there. You write the SQL, you decide the shape of the query, and the library handles the materialisation of rows into your types. EF Core starts one level higher: you write C# against a model, and the provider produces the SQL. Change tracking and migrations only exist in the second model, because only EF Core has a model to track against and to diff.

That produces a clean decision rule. If the query is the artefact you care about, Dapper keeps it visible. If the object graph is the artefact you care about, EF Core lets you express operations on it and generates the statements. The README's example is squarely in the second category: Add, SaveChanges, OrderBy, First, Remove, SaveChanges. There is no SQL anywhere in it, and that is the point of the library.

A second comparison worth naming is EF6 versus EF Core, which appears in the search data as a speed question. The repository README contains no benchmark numbers and no comparison to EF6, so any performance claim would be invented. What the README does establish is that EF Core is the current project, with releases for .NET 8, 9 and 10 published in September 2026, and that EF6 is not part of this repository at all.

Release cadence, versions and what an upgrade costs

The recent releases are v10.0.12 for .NET 10.0.12, v9.0.20 for .NET 9.0.20 and v8.0.31 for .NET 8.0.31, all dated 2026-09-08. Three lines are maintained in parallel, which is the practical shape of the upgrade story: you choose a major line, you stay inside it, and patch releases arrive for it. The repository's last push was on 2026-09-21, so the codebase is being worked on continuously rather than frozen.

The cost of an upgrade is not the package bump. It is the model and the migrations. A major version can change how the model is translated, and the repository's own solution filters show how the code is split: EFCore.Runtime.slnf, EFCore.Relational.slnf, EFCore.Sqlite.slnf, EFCore.Cosmos.slnf and EFCore.Tools.slnf. The runtime surface, the relational layer, individual providers and the tooling are separable, which means a provider can lag the core. Before you upgrade, check that the provider package you depend on has a release on the same major line.

The licence is MIT, stated in the README and present as LICENSE.txt at the repository root. That permits commercial use and modification. It is not legal advice, and the README makes no warranty claims beyond what the licence text says; read LICENSE.txt if the terms matter to your organisation.

Support runs through Stack Overflow for usage questions and the issue tracker for bugs and feature requests, per the README. There is no commercial support commitment described in the repository README itself.

Editorial conclusion

Adopt EF Core when your domain is object-shaped, your team writes C# daily, and you accept that generated SQL is something you inspect rather than author. Do not adopt it for a handful of hand-tuned queries against a schema you do not own, or for a hot path where you need the exact statement text. Verify first that a provider exists for your database at the version you intend to run, that the package version matches your .NET target, and that your migration workflow is settled before the first schema change reaches production.

Frequently asked questions

Official sources

1. dotnet/efcore on GitHub
2. License: MIT
3. Project website
4. README
5. Releases