I think there's some false equivocation going on here. When you point out that behind the scenes rows sit adjacent to each other on disk in an RDBMS, that's th

I think there's some false equivocation going on here. When you point out that behind the scenes rows sit adjacent to each other on disk in an RDBMS, that's the same thing that's happening behind the scenes with documents... they're sitting adjacent to each other on disk. Documents instead of rows is all: and guess what, a flat document without nested documents or arrays is a relational style row. You jump to the ability to get speed up operations with column scoped operations, but really what you're getting at here is a question of indexing... in a document oriented database with rich secondary indexes you can do aggregations across fields (fields are like columns in an RDBMs but in a document) which can include arrays. Frankly that's why it's so important to have consistent secondary indexes that can express the breadth of your query patterns and evolution therein and frankly it's why key/value stores like dynamodb are absolutely not general purpose, in other words cannot be used to express bread and butter workloads that folks would have used RDBMS for in the decades leading up to this moment. You are correct that column store engines are a different category entirely optimized for super efficient lookups on individual columns as opposed to entire rows and therefore are less optimized for updates: but again frankly there's no reason why this can't actually express a document structure it's just custom running back to the 1970s that causes us to think and use terms like this. Now bringing up joins is a great point, and it's true that one of the things document databases allow people to do is store data in a denormalized way which offers scalability opportunities and perhaps more importantly a way to store data the way you think about it in your code but this is certainly not a requirement... it's just the best practice where appropriate. You still have to express different business objects in distinct parts of your data model and occasionally have to join them.. join performance is simply a question of the engine's implemented optimizations and is not related to the data model. By the way, graph databases maintain data structures optimized for closeness but there's frankly no reason why such a data structure can't be also an optimization on another data engine, again it's essentially distinct from the data model; the industry has leaned into a false understanding that somehow these all need to be separate categories by default.