Hacker News new | ask | show | jobs
by joshberkus 3072 days ago
Yes, that's correct. If you are going to use sync rep because you can't lose transactions, you really want to use the latest version of PostgreSQL, which supports quorum sync (i.e. "one of these three replicas must ack"), even in complex configurations ("one replica from each availability zone must ack"). Note, though, that the existing HA automation solutions (Patroni, Stolon) don't currently have support for complex topographies, so you'd need to do some hacking.

It is a tradeoff though. With synch rep, you are at a minimum adding the cost of two network trips to the latency of each write (distributed consistent databases like Cassandra pay this cost as well, which is why they tend to have relatively high write latency). It turns out that a lot of users are willing to lose a few transactions in a combination failure case instead of having each write take three times as long.

Postgres also has some "in between" modes because write transactions can be individually marked as synch or asynch, so less critical writes can be faster. I believe that Cassandra has something similar.