// the find
dotnet/efcore
EF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.
EF Core is the official Microsoft ORM for .NET, handling LINQ-to-SQL translation, change tracking, and schema migrations across SQL Server, PostgreSQL, SQLite, Cosmos DB, and others. It's the default choice for .NET applications that need a database layer — not because it's always the best tool, but because it's deeply integrated with the ecosystem and maintained by the runtime team. If you're writing a .NET app that touches a relational database, you'll probably end up here.
The LINQ query translation is genuinely impressive — complex joins, projections, and aggregates generate reasonable SQL that you'd write yourself. The provider model is solid: switching from SQLite in tests to SQL Server in production works without touching your queries. Migrations are first-class: incremental, source-controlled, and handle most schema changes without hand-editing SQL. The change tracker handles graph updates (adding related entities, updating disconnected graphs) correctly in ways that Dapper users have to manage manually.
Query compilation has real startup cost — the first query against a DbContext type is noticeably slow, which is why DbContext pooling exists but adds its own lifetime management complexity. The Cosmos DB provider is a persistent embarrassment: it maps a relational model onto a document store badly, discards most Cosmos-specific features, and the query support is full of sharp edges that only surface at runtime. N+1 queries are still easy to accidentally write — nothing stops you from loading a list of orders and then accessing `.Customer` in a loop. The abstraction also leaks: once you need raw SQL for performance or provider-specific features, you're writing `FromSqlRaw` strings that EF can't validate at compile time.