The anti pattern is not the tools but how the tools are used. ORM is abused a lot by people that don't necessarily understand databases very well. This abuse le

The anti pattern is not the tools but how the tools are used. ORM is abused a lot by people that don't necessarily understand databases very well. This abuse leads to overly complicated table structures based on an illusion that the ORM tries to keep up that internal domain models map 1 to 1 to the database. This is basically self inflicted pain. If you've never heard about the object impedance mismatch, that's basically the problem with modern object oriented application architectures and trying to shoehorn that into a database. Complex table structures have all sorts of issues related to complex database migrations and operational overhead related to that, additional complexity in the form of lots of joins, a need for indices to support those, all sorts of cascading behavior when things are updated or deleted, transactionality issues, and so on. That complexity tends to leak back into applications. If you know what you are doing, you can avoid all of that of course. But there are a lot of examples of people using ORMs where things get a bit messy. I've fixed a fair few projects where hibernate usage got out of hand a bit. These are not fun projects to join usually. Performance issues, flaky behavior, wonky test failures (and slow tests), etc. Usually a good way out is to cut down on the number of tables. My mantra is that if you aren't querying on it, maybe it can just be a json blob instead of a lot of silly tables and columns that need to be joined together. I like document stores. And you can easily adapt sql databases to build one that has nice transactional behavior. A few years ago I consulted a company to help them build them a search engine. They had completely over-engineered their data model, spent months obsessing on their domain model, and there were 20 or so tables and all the usual issues related to that (hard to extend, issues with complex transactions, stupidly complicated joins, etc.). Basically, I sat their tech lead down and went over the requirements: - get a thing by id - do some CRUD on things - put all the things in the search index (for each thing do X) - use the search index to find things That's it. The whole point of the system was to act as a single source of truth for the search index. So, I told them: that sounds like you need 1 table with a json blob to represent your thing. We had a few other columns for things like timestamps, userIds, etc. That vastly simplified the application architecture. We could add features without requiring a lot of database migrations. Etc. All good things.