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 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.
> 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.