Well, just assume that I'm also speaking from experience of delivering complicated applications to production and I'm tired of how ORMs become a pain in the lon

Well, just assume that I'm also speaking from experience of delivering complicated applications to production and I'm tired of how ORMs become a pain in the long term: - they create a dangerous illusion of an leaky abstraction which leaks very quickly - they require programmers to learn 2 things anyway - they initially speed up the coding, but later slow it down, esp. when you have to tune stuff (how many times you peeked generated SQLs only in order to feed them to EXPLAIN ANALYZE... ?) - they can promote bad habits, code which takes your engine to a crawl - they hinder debugging, esp. tracking performance problems, often effectively putting a problem under the carpet to be discovered by admins There's also a funny thing: most of the world seems to happily use active record (as a pattern), although when you go deep into it it occurs far inferior to data mapper (as a pattern). That also demonstrates that many people are using habits, not engineering, and stick to what's used around instead of making some investigation on the topic. This is not bad per se; but when it comes to discussing problems, such people are not in the position to argue, precisely because they haven't done their homework. So, the problems above are caused by the mismatch which one can expect from the theory. You've got what you paid for. I guess we all could learn most from the history of relational databases or just try to remember what relational databases really are and what other examples of this technology are around. For example Prolog is relational (apart from logic engine). If one does something in it then it becomes more clear how much it "fits" objects or not.