I'm not porcupine, but I feel that we are definitely using relational models. The drive towards objects (and REST as well) tries to project data into a hierarch

I'm not porcupine, but I feel that we are definitely using relational models. The drive towards objects (and REST as well) tries to project data into a hierarchy. Orders belong to customers, so you nest orders under customers. But you are B2B, so you break into one market and realize that suddenly joint purchases are a thing. Suddenly you have orders with multiple customers. If you were using a relational model for backing the orders and customers, there is no real issue. An order is just a tuple of data, a customer is just a tuple of data, the "belongingness" is just modeled via foreign key constraints. Maybe you were smart enough to already model it as many to many and you just relax a uniqueness constraint in the join table or you had no such uniqueness constraint already and it was enforced by the application. Otherwise, you move the foreign key out of the order tuple into a joining table and move on to changing the projection queries and the downstreams. If you were storing it as nested data documents... I don't know because I have never done that, but I do know the trouble with trying to invert hierarchical addresses in such cases and it is annoying and inefficient (abstraction inversion). In a relational model, any hierarchy is a contrivance via foreign key constraints. These same attributes are easy to invert. If you have a business need for a hierarchy, that shows up in the business logic by the precise query used to project the relations along the foreign keys. In the scope of the comment made. I find it hard to believe that someone doesn't see that we are indeed using relational models of data and I find it sad that the known benefits apparently aren't so widely known. Yes, in a concrete use case you project out the data you need and type that (map it to objects). But if you modeled the data well, as your use cases increase in number or evolve your data model often doesn't need to change as much as your business logic if you did your job well. The job being relational data modelling. I myself use async programming, and there aren't really good ORMs for that since you don't want every single property of your object to be an async property (which most ORMs do with lazy loading).