So, in summary, ORMs are only bad when you use the ORM parts and not when you mostly ignore the ORM parts and only primarily use the query generator and basic a

So, in summary, ORMs are only bad when you use the ORM parts and not when you mostly ignore the ORM parts and only primarily use the query generator and basic abstraction parts. Well yes, that's because whenever things get hairy, you're no longer dealing with an ORM, you're dealing with the query generator. You don't have to translate your complex graph queries into their relational variants by manipulating the output of an ORM. And I have to agree that query generators have a hell of a lot more value and are way less likely cause trouble than ORMs. So yes, ORMs are no longer an anti-pattern, because most modern ORMs aren't really ORMs anymore, and when they are, they either swallow the performance hit and resulting issues when trying to compensate or don't encourage you use the ORM parts except for very specific cases, and instead encourage you to use the far more powerful query generator parts and all the random mild abstraction parts. The question left is, is it better to just learn SQL including the specific variant of SQL you're targeting, or is it better to instead learn a specific query generator and its database specific parts? Addendum: Really, at this point I don't think it matters what people use, the number of people who actually know how to design a database is insignificant compared to the people who are tasked with designing them. I am now all but convinced that the reason ORMs are popular is because they make it slightly quicker and easier to deal with a fucked up database design than having to do the same with pure SQL or a query generator.