I've always been a fan of Dapper for its raw speed and control over SQL. However, with all the improvements in EF Core 8, like the better support for JSON columns and raw SQL mapping, is the performance gap still significant enough to justify writing manual queries for everything?
3 answers
The performance gap has narrowed significantly. EF Core 8 is remarkably fast, and for 90% of standard CRUD operations, you won't notice a difference in real-world API response times. The developer productivity gains—like migrations, change tracking, and strong typing—usually outweigh the micro-optimizations of Dapper. Plus, EF Core now supports "Compiled Models" and "No-Tracking" queries which bring it very close to Dapper's speed. I usually recommend a hybrid approach: use EF Core for the majority of the app to save time, and pull in Dapper only for that one "monster" reporting query that needs manual SQL tuning.
How does EF Core handle complex joins compared to Dapper? I've seen some pretty ugly SQL generated by LINQ in older versions of Entity Framework.
Migrations alone make EF Core worth it for me. Managing database schema changes across dev, staging, and prod is so much easier than running manual scripts.
I'm with Sarah. The ability to version control your database schema alongside your code is a fundamental requirement for modern DevOps practices
Gary, the SQL generation in EF Core is much cleaner now. It handles "N+1" query issues better and has specific features like AsSplitQuery() to prevent Cartesian explosion on complex joins. You can also easily view the generated SQL in your debug console or use a tool like EF Core Power Tools to visualize the model. If a LINQ query is still producing inefficient SQL, you can always drop down to FromSqlRaw while still benefiting from EF's object mapping capabilities.