My experience has been that ORMs generally 'suck' outside the trivial CRUD use-cases, and it's usually faster and simpler just to write native queries again you

My experience has been that ORMs generally 'suck' outside the trivial CRUD use-cases, and it's usually faster and simpler just to write native queries again your database. I've used hibernate, linq, active record and mongoose in real production applications, and pretty much every time the same sequence of events happen. 1) Wow, this ORM is so cool, I've saved so much time as I dont need to learn anything about the underlying DB. 2) New feature comes in that requires something other than CRUD. Oh how do I do this with the ORM. Either you extend it with plugins, or learn the ORM query language that's kinda like the native query language but worse. 3) Now we got some real data, why is it slow as hell? Oh, those 'cool' abstractions are creating n^2 queries, implicit joins, etc 4) Let's rip apart the ORM, and use a thin layer that just execute the native queries. A few years back I worked on a quant finance application that had 100GBs of tick data in a oracle DB, and the only way to get reasonable performance AND abstraction was to write optimised stored procs for each feature in the end application, and have the middle tier just call them through a thin abstraction layer. At our startup dump.ly, we started with using Mongoose with Mongo because it was so easy just to persist some JSON data. However very quickly we went thought the above loop, and are now 100% Redis, with a thin layer that executes native Redis commands. It just ended up being simpler and faster. Takeaway is that in general ORMs are an anti-pattern. Every DB (noSQL or yesSQL) is a compromise between a set of features, performance, consistency, scalability etc. You need to understand these in detail and hence should not be abstracted away.