EF Core vs Dapper

Analogy categoryAnalogies

Two Different Philosophies for Talking to a Database

EF Core is a full-featured object-relational mapper that generates SQL from LINQ, tracks entity state, manages migrations, and resolves relationships automatically through navigation properties. Dapper is a micro-ORM built by the Stack Overflow team that maps query results onto plain objects with minimal overhead but leaves you to write your own SQL by hand. Neither is strictly better; they optimize for different things — EF Core optimizes for developer productivity and abstraction over the database, while Dapper optimizes for raw execution speed and explicit control over exactly what SQL runs.

🏏

Cricket analogy: EF Core is like an all-rounder such as Ben Stokes who handles batting, bowling, and captaincy so you don't need three separate specialists, while Dapper is a specialist fast bowler like Jasprit Bumrah brought in for one precise job — raw pace with no extra overhead.

Performance and Control Trade-offs

Dapper typically outperforms EF Core on raw read throughput because it skips LINQ-to-SQL translation, change tracking, and the query pipeline's expression tree compilation, mapping results directly onto POCOs with a thin reflection-based layer. EF Core's overhead is usually acceptable for typical CRUD applications, and compiled queries plus AsNoTracking() close much of the gap for hot paths, but in scenarios with extremely high query volume — reporting dashboards, bulk exports, or latency-critical APIs — teams often drop to Dapper or raw ADO.NET for the specific queries that matter most, while keeping EF Core for everything else.

🏏

Cricket analogy: A specialist death-over bowler like Rashid Khan is brought on specifically for the last few overs where every run matters, the same way teams drop to Dapper only for the specific high-volume queries where every millisecond matters.

csharp

// EF Core: LINQ query, automatic tracking, navigation properties resolved for you
var orders = await dbContext.Orders
    .Where(o => o.CustomerId == customerId)
    .Include(o => o.Items)
    .ToListAsync();

// Dapper: hand-written SQL, explicit mapping, no tracking overhead
using var connection = new SqlConnection(connectionString);
var orders = await connection.QueryAsync<OrderDto>(
    "SELECT Id, CustomerId, Total, Status FROM Orders WHERE CustomerId = @CustomerId",
    new { CustomerId = customerId });

When Teams Combine Both in the Same Application

It's common and well-supported to use EF Core and Dapper side by side within a single application, often by sharing the same underlying DbConnection so both tools participate in the same transaction. A typical pattern is to use EF Core for the bulk of CRUD operations, migrations, and schema management, while writing specific Dapper queries for reporting endpoints, bulk read operations, or stored procedure calls where the overhead of LINQ translation isn't worth paying. Dapper.Contrib and similar extensions can even provide lightweight CRUD helpers on top of Dapper for teams that want its performance without hand-writing every insert and update statement.

🏏

Cricket analogy: A team fields both an all-rounder for general overs and a specialist death bowler for the final overs of the same match, the way an application uses EF Core for general CRUD and Dapper for the specific reporting queries that need raw speed.

EF Core and Dapper can share the same open ADO.NET connection and even the same transaction. Call dbContext.Database.GetDbConnection() to get the underlying connection, and pass dbContext.Database.CurrentTransaction?.GetDbTransaction() into Dapper's query methods to keep both tools consistent within one unit of work.

Dapper does not protect against SQL injection automatically the way LINQ does — you are writing raw SQL strings, so always use parameterized queries (the @Parameter syntax) rather than string concatenation or interpolation of user input.

EF Core is a full ORM with LINQ translation, change tracking, and migrations; Dapper is a lightweight micro-ORM that maps hand-written SQL onto objects.
Dapper generally has lower per-query overhead because it skips expression tree compilation and change tracking.
EF Core's compiled queries and AsNoTracking() narrow, but don't eliminate, the performance gap for hot paths.
Many teams use EF Core for general CRUD and migrations, and Dapper for reporting or latency-critical queries.
EF Core and Dapper can share the same connection and transaction for consistency within one unit of work.
Dapper requires manually parameterizing SQL to avoid injection risk, since it doesn't build queries through LINQ.