I think it's all about getting to know the tool (ORM) you work with. Look at the generated queries and their performance, use eager/lazy loading in the right pl

I think it's all about getting to know the tool (ORM) you work with. Look at the generated queries and their performance, use eager/lazy loading in the right places and mainly take care of the database operations that run most often. Switching to plain SQL might make sense if you don't need structured/hierarchical objects at this point in your application and a simple array/list/table will do just fine. Don't bother with that if your hand-generated query will most likely end up the same though. Use database-specific bulk imports or plain SQL if you have lots of data to insert and need it fast. I am also often seeing comments about ORMs saying "What's so hard about SELECT..." - nothing's really hard about retrieving data, every decent developer will sooner or later end up with a working complicated SQL that gets them exactly what they wants. But I think the real benefits of ORMs start when you have to save/edit/update/extend relational data again and have to take care of all the inserts, updates, deletes across several tables, maybe including versioning or workflow (drafts or changes waiting for approval) and other additional complexity on top. That's the parts where I am glad to rely on an ORM supporting relationships and which can be extended via hooks or behaviours. (Note that I am mainly talking about 'Admin' pages here and nothing that runs too often.)