I'm starting a fresh ASP.NET Core Web API project and trying to decide between Dapper and EF Core for data access. I've heard EF Core is the "standard" choice, but Dapper keeps coming up in performance discussions.
What are the real trade-offs here? I'm not looking for a generic "EF is ORM, Dapper is micro-ORM" explanation — I want to know how they behave under load, how much boilerplate each requires for a typical CRUD API, and whether Dapper's lack of change tracking will bite me later.
- Setup complexity: How hard is it to wire Dapper into the built-in DI container compared to EF Core's migrations and DbContext?
- Query flexibility: If I need raw SQL for a reporting endpoint, does Dapper make that trivial while EF Core forces me into raw SQL strings anyway?
- Maintenance: Will my team struggle with Dapper's manual mapping, or is EF Core's convention-over-configuration actually a net win?
Curious what people are using in production right now for medium-scale APIs. Any war stories welcome.
For most new ASP.NET Core APIs, I’d start with Entity Framework Core. It gives you a productive default: LINQ queries, change tracking, relationship handling, and a migration workflow for evolving the database alongside the application.
Dapper is a strong choice when you want to write and tune SQL directly. It’s a lightweight micro-ORM: you provide the SQL, and Dapper maps the results to your objects. That can make it a good fit for read-heavy API endpoints or a service with carefully optimized, database-specific queries.
What matters for your API?
Don’t choose Dapper solely on the assumption that it will make the whole API faster. Performance depends heavily on query shape, indexes, database round trips, and how much data the endpoint loads. EF Core can perform well when queries are designed carefully; Dapper still needs well-written SQL.
For a new project without unusual constraints, EF Core is usually the easier starting point. You can introduce Dapper for specific queries if measurements show a need or if those queries are simpler to manage as SQL. The best choice is the one your team can keep clear, testable, and well-tuned.