I've seen quite a few instances where a mongo deployment using both of those can comfortably be replaced by a single postgres primary (on about the same hardware as a single member of the mongo cluster) with a couple of read replicas and a connection balancer.

There are absolutely mongodb deployments out there that are at sufficient scale that they genuinely need those features in any storage backend, but I suspect the vast majority of them only need those features to work around mongo's mediocre straight line performance.

How close this comes to counting as "almost all" is of course highly arguable.

> can comfortably be replaced by a single postgres primary

And lose all the data in a single failure?

I said a single -primary- and explicitly mentioned having replicas.

I'm very confused why you might think that could "lose all the data" from a single one of those nodes failing.

I was reading your reply too quick, sorry. Anyway, even failover replication in PG is not there out of the box and have it's quirks.

I don't disagree at all with that statement although invetably what mongo does have out of the box definitely has its own quirks.

Getting operations right is tricky no matter what you're doing/using, and you always have to learn your backend's idiosyncracies no matter which one you choose.

It has both, but not out of the box.

More info?

What's vertical replication?

Having several read-only replicas in every shard to distribute reading load.