3 ms·

> If they got their clustering story to be as easy as MongoDB's was 5 years ago You must have been using a different mongodb than I did.

sroussey 8y ago
On paper. Add that to the end of that sentence, and it will be true again.
Townley 8y ago
One of the things I liked about Mongo (compared to Postgres) was the ability to configure a list of connected servers, an election pattern for deciding the master, and... that's it. With that, servers on multiple hosts were load-balancing read-only queries, propagating writes, and failing over in a way that worked for us (a few seconds of write failures of the master ever died was fine for the application we were making). Meanwhile, postgres has this replication scheme available ("Trigger-Based Standby Master Replication") but the steps to implement it were much harder, and required an evaluation of possible replication/failover needs that we didn't know enough to do. It also requires a dive through pages of the documentation at https://www.postgresql.org/docs/10/different-replication-solutions.html https://www.postgresql.org/docs/10/different-replication-sol... to understand how to implement any of the above strategies. Postgresql's availability of different replication methods, and the resources available for each, are impressive for sure. But there's something to be said for having Mongo's easily-understandable list of steps to get multiple servers talking to each other right away.
- SahAssar 8y ago
  Out of interest, have you tried https://github.com/zalando/patroni https://github.com/zalando/patroni ? It seems to fill this niche. I've been meaning to try it out for the HA postgres use case, but haven't gotten around to it.
atonse 8y ago
I won't speak to data integrity, but as the other poster said, you just had to set up the replication, election mechanisms and you were done. I bet Citus is like this, but I haven't used it yet.

sroussey 8y ago

On paper. Add that to the end of that sentence, and it will be true again.

Townley 8y ago

One of the things I liked about Mongo (compared to Postgres) was the ability to configure a list of connected servers, an election pattern for deciding the master, and... that's it. With that, servers on multiple hosts were load-balancing read-only queries, propagating writes, and failing over in a way that worked for us (a few seconds of write failures of the master ever died was fine for the application we were making). Meanwhile, postgres has this replication scheme available ("Trigger-Based Standby Master Replication") but the steps to implement it were much harder, and required an evaluation of possible replication/failover needs that we didn't know enough to do. It also requires a dive through pages of the documentation at https://www.postgresql.org/docs/10/different-replication-solutions.html https://www.postgresql.org/docs/10/different-replication-sol... to understand how to implement any of the above strategies. Postgresql's availability of different replication methods, and the resources available for each, are impressive for sure. But there's something to be said for having Mongo's easily-understandable list of steps to get multiple servers talking to each other right away.

SahAssar 8y ago
Out of interest, have you tried https://github.com/zalando/patroni https://github.com/zalando/patroni ? It seems to fill this niche. I've been meaning to try it out for the HA postgres use case, but haven't gotten around to it.

atonse 8y ago

I won't speak to data integrity, but as the other poster said, you just had to set up the replication, election mechanisms and you were done. I bet Citus is like this, but I haven't used it yet.