It's a case of "I want to keep all my data on the same place" because nobody has the attention span to manage a relational database, a document database, an hierarchical database, and a key-value database (did I miss any?). All that while you lose atomicity, because your data is now distributed.
Also, data often changes in form, and you don't want to rewrite everything to get the data from a different place just because its type changed.
I've heard it said of Python that it's the second best language for doing anything. For one specific task, there's probably something more tailored to the purpose. For integrating lots of different tasks into a single project, there's nothing that's better at doing everything pretty well.
I see PostgreSQL the same way (although I don't think there's a better RDBMS). It's not the best document database, but it's pretty good. It's not the best key-value store, but it's pretty good. It's not the best graph database, but it's pretty good. And here "pretty good" means "enough that you can build large, complex projects on top of it and expect that it will always work and do the right thing".
Also, the converse is not true: you can't replace PostgreSQL with a K-V store, or a document database, or a graph database. It has a million convenient features that nothing outside of another ACID RDBMS could fully support without massive engineering efforts. Unless I know beyond the shadow of doubt that I'd need, say, a dedicated document database for a specific reason, I'd infinitely rather start on PostgreSQL and use it until we outgrow it, than start with something like MongoDB and find out that we actually need some ACID or relational features that don't exist in Mongo.
I like thinking about the best tools for the job, or "jobs to be done" as Clay Christensen would put it. But why wouldn't you use MongoDB for things that require ACID? MongoDB has had cross-collection ACID transactions since 4.0 (years ago) and in-collection transactions (less useful, of course) since a long time before that.
PostgreSQL is indeed a pretty awesome database. That said, the JSON support is just so very painful. It's nice that it supports indexes on JSON, though, once you get through the syntax.
Thanks for your post.
> Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations.
I would not use that where data integrity is mission critical.
2020-05-26: MongoDB identified a bug in the transaction retry mechanism which they believe was responsible for the anomalies observed in this report; a patch is scheduled for 4.2.8.
Lots of databases have transaction bugs which they hurriedly rush out patches to. MySQL, Oracle, SQL*Server, even the cloud databases like DynamoDB, CosmosDB, Aurora. Looks like MongoDB fixed this one.
Also, data often changes in form, and you don't want to rewrite everything to get the data from a different place just because its type changed.