I've had to clean up ORM mess in a few projects. ORM mess is what you get when you have people that have very little experience with databases abuse ORMs to pre

I've had to clean up ORM mess in a few projects. ORM mess is what you get when you have people that have very little experience with databases abuse ORMs to pretend that what they have in their database is the same as they have in their domain model. Usually the signs are that they have transactional issues, severe performance issues, and lots of time wasted on analyzing why stuff isn't working as expected. Not my favorite job. Learn to do a proper database design; it's not that hard. Balance denormalization against querying needs (disk space is cheap). Use json serialized objects to your advantage for complex things that you don't actually query on. The price you pay for adding complexity to a database is query time overhead, joins, and the resulting application level complexity, bugs, and overhead. You'll need lots of columns with indices to support all that. The queries get more complex and expensive. Etc. Needless complexity at the database level is not a good thing. Keep it simple. Mostly, you don't need your database model to resemble your domain model. You just need it to store it. A simple database model could be a table with a key and a json blob. Perfectly valid for a lot of domain models. And databases like postgres support creating indices on things inside your json. So, you don't even lose the ability to query. If you really need extra columns (e.g. a timestamp), add them of course. The mistake that people make is assuming that all the little objects in their domain are equally important. They are not. Most of it is just meta data that needs to be attached to something that is never/rarely used for querying. It needs to live somewhere. But that doesn't necessarily have to be a dedicated column or table in a database.