With ORMs I tend to write things with their native syntax, and then if necessary go back and speed up critical sections with SQL; it's not an either/or situation.

That was a long time ago. I believe it was based on EF and not on EF core. Is there any up to date benchmark that you are aware of? BTW I used both Dapper and EF for consumer based web applications with a mild load. Dapper is a nightmare to use compared to EF. Dapper was chosen by the customer architect as mandatory because probably of the same benchmark that you are referring to. The result has been that we had to write tons and tons of code to cover things that come out of the box in EF such as 1 to many relationships. Also every change in the schema forced us to review the full persistence layer to evaluate the impacts. I would reccomend Dapper only for websites dominated by SELECT queries on databases with simple DB schemas and only when some millisecond more make a difference. This wasn't absolutely the case for our application ( complicated DB schema and 5 ms vs 30ms spent in the ORM doesn't make any difference at all) while probably IT IS StackOverflow case. There is no such a thing as something slow or fast in absolute terms: it all depends on the context and as software engineers and even more architects we are called to judge with our brains everything in context rather than rely on a blog post written by somebody else.

>Stackoverflow did a test once

That was long time ago and EF improved a lot since then.

But it can be slow if used improperly. But hand written SQL can be slow too if not carefully crafted.