4 ms·

A large reason to use Postgres in the first place is because it's a good CP system. Any clustered version is only worthwhile if it preserves consistency. It's

by lucian1900 11y ago

A large reason to use Postgres in the first place is because it's a good CP system. Any clustered version is only worthwhile if it preserves consistency. It's already possible to use more than one Postgres database while not maintaining consistency, but that isn't desirable for most users.

antirez 11y ago
> it's a good CP system PostgreSQL is not clustered by default so it is only from the point of view of the theory a CP system. Most proper CP systems have the ability to provide a limited form of Availability, which is, they are available in the majority partition (this is not "A" of CAP but is a lot better than, if primary is not available, the whole cluster is not available). If you use PostreSQL with asynchronous replication and a best-effort failover solution to provide some form of Availability, you are doing something that makes sense, assuming your product can tolerate the resulting weak consistency properties. This is a great example on how CAP does not capture certain important semantics of a system. Technically a single primary node is CP but the real world CP systems have better availability than that, or they are useless (as CP systems).
takeda 11y ago
There are two separate problems: - clustering to increase performance - clustering for HA Most people want at least the later one. The former one is a bigger challenge in case of relational databases so I'll ignore it here. Regarding consistency vs availability typically is not all black and white, and people are willing to make tradeoff. For example losing few transactions as opposed to being completely down. This is not too bad as long as developers are aware of that special case and write code that can handle that. Having said that, I'm wondering how a failover system based on BookKeeper[1] would work (a relational database is effectively a state machine, so seems like this could fit). The tradeoff here would be most likely reduced performance though. [1] http://bookkeeper.apache.org/ http://bookkeeper.apache.org/

antirez 11y ago

> it's a good CP system PostgreSQL is not clustered by default so it is only from the point of view of the theory a CP system. Most proper CP systems have the ability to provide a limited form of Availability, which is, they are available in the majority partition (this is not "A" of CAP but is a lot better than, if primary is not available, the whole cluster is not available). If you use PostreSQL with asynchronous replication and a best-effort failover solution to provide some form of Availability, you are doing something that makes sense, assuming your product can tolerate the resulting weak consistency properties. This is a great example on how CAP does not capture certain important semantics of a system. Technically a single primary node is CP but the real world CP systems have better availability than that, or they are useless (as CP systems).

takeda 11y ago

There are two separate problems: - clustering to increase performance - clustering for HA Most people want at least the later one. The former one is a bigger challenge in case of relational databases so I'll ignore it here. Regarding consistency vs availability typically is not all black and white, and people are willing to make tradeoff. For example losing few transactions as opposed to being completely down. This is not too bad as long as developers are aware of that special case and write code that can handle that. Having said that, I'm wondering how a failover system based on BookKeeper[1] would work (a relational database is effectively a state machine, so seems like this could fit). The tradeoff here would be most likely reduced performance though. [1] http://bookkeeper.apache.org/ http://bookkeeper.apache.org/