[lima]

Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions. It would not pass the Jepsen test suite.

This is very hard to fix and requires significant architectural changes (like Yugabyte or Neon have done).

[riku_iki]

> Postgres is not a CP database, and even with synchronous replication, it can lose writes during network partitions.

Argument is that partitioning almost never happens, because of network reliably rerouting traffic.

[lima]

Reliable networks don't actually exist[1].

Clearly, it's possible to reduce the risk to the point where many companies are willing to accept it, but it's still a problem and comes with high operational costs. And for some use cases (like finance), even a small risk of undefined database behavior or lost writes is unacceptable.

The future are distributed databases with consensus, and unfortunately, Postgres isn't there yet.

[1]: https://aphyr.com/posts/288-the-network-is-reliable

[riku_iki]

reliable network and partitioning are two different things.

If your network is down, your clients can't connect DB too, and nothing works. State of network partitioning is harder to achieve, its more like if connection between two datacenters is down where DB replicas live, which is more rare because of all global connection redundancy.

[lima]

It's really the same thing. Network partitions can (and do) occur within a single DC.

> If your network is down, your clients can't connect DB too, and nothing works

This sounds simple, but can only be achieved with high certainty using distributed consensus.