For documents it made access fast since there’s no joins, etc. that require paging from all over. The problem ended up being updates and compaction issues.
My memory is that the problem was ACID. The document stores didn’t promise to be reliable because apparently that didn’t scale.
And there was a very well known cartoon video discussion about it with “web scale” and “just write to dev null” and other classics that became memes :)
Did you ever read Pat Helland's article, "Life Beyond Distributed Transactions: An apostate’s opinion" https://dl.acm.org/doi/10.1145/3012426.3025012? "This article explores and names some of the practical approaches used in the implementation of large-scale mission-critical applications in a world that rejects distributed transactions."
Admittedly I live in a world where big distributed transactions are a given and work fine and sql speeds us up not slows us down. I’m guessing sql and acid scaled after all?
Yes and no. Distributed transactions and two-phase commit have been superseded by things like Paxos and Raft, with a variety of consistency models, so the implementation is drastically different.
Document stores often are reliable and more fault tolerant. But yes they trade ACID.
There are some applications that require high throughput (usually write) but can be fine with read consistency.
Couple of examples
- consumer facing comment systems where other users are OK to miss your comment by 30 seconds
- timeseries logging where you are usually reading infrequently but writing very much in a denormalized format so joins aren't as critical
And there was a very well known cartoon video discussion about it with “web scale” and “just write to dev null” and other classics that became memes :)