3 ms·
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 hardwar
by mst 5y ago
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.
- SergeAx 5y ago> can comfortably be replaced by a single postgres primary And lose all the data in a single failure?
- mst 5y agoI 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.
- SergeAx 5y agoI 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.
- mst 5y agoI 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.