I believe it depends on what problem you are trying to solve. Surprisingly nobody has mentioned this in the thread, but domain-driven design (DDD) encourages yo

I believe it depends on what problem you are trying to solve. Surprisingly nobody has mentioned this in the thread, but domain-driven design (DDD) encourages you to split your problem domain into different bounded contexts (BC) and use the right architecture for each BC. Classic example is an event booking system: (a) Event Management is basic CRUD, so you use an ORM everywhere. There are no complicated queries here so ORM objections don't count. (b) Ticket Management has multiple users, race conditions, performance requirements, etc. so maybe go the command-query separation (CQRS) route and use a full ORM for your write model and raw SQL, possibly a micro-ORM, for your eventually-consistent read model. Why use a full ORM? You get to write your domain logic in your high level language with full unit testing, and the ORM worries about mapping this back to the database, dealing with concurrency and retry strategies automatically. For this to work you have to carefully design your business transactions against small aggregates containing a handful of entities, which is difficult to get right initially but has many advantages. (c) Payments/Refunds are transactional, reliant on external services, and need a full audit history so maybe consider an event sourced approach with no ORM visible. (d) Reports have no write model, so an ORM holds little advantage. Use SSRS, Power Bi, QlikView, etc. etc.