---
title: "Dapper vs Entity Framework Core: Which is better for a new ASP.NET Core API?"  
description: "Dapper vs Entity Framework Core: Which is better for a new ASP.NET Core API?"  
author: "Manish Sharma"  
published: 2026-09-30  
updated: 2026-10-12  
canonical: https://www.mindstick.com/forum/162225/dapper-vs-entity-framework-core-which-is-better-for-a-new-asp-net-core-api  
category: "Data Access"  
tags: ["Dapper", "Entity Framework Core", "ASP.NET Core", "Web API", "data access"]  
reading_time: 3 minutes  

---

# Dapper vs Entity Framework Core: Which is better for a new ASP.NET Core API?

I'm starting a fresh ASP.NET Core Web API project and trying to decide between [Dapper](https://answers.mindstick.com/qa/user/642061/be-dapper-uk) 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.

## Replies

### Reply by Steilla Mitchel

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?

- **Choose EF Core** if the API has a typical domain model, frequent create/update operations, and a team that benefits from working mostly in C#.
- **Choose Dapper** if SQL control is a priority, the data access layer is small, or the application relies on queries that are clearer to maintain as SQL.
- **Consider both** if most operations fit EF Core but a few complex reports or high-volume reads are easier to express and tune with Dapper.

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.


---

Original Source: https://www.mindstick.com/forum/162225/dapper-vs-entity-framework-core-which-is-better-for-a-new-asp-net-core-api

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.