liveBook · Manning

PACELC theorem

As explained in PostgreSQL Mistakes and How to Avoid Them

The PACELC theorem describes the tradeoff between consistency and availability during partition and between latency and consistency when the system is operating normally.

PACELC names unavoidable distributed-system tradeoffs. During a network partition, a system must choose availability or consistency; otherwise, it chooses between latency and loss of consistency. Consistency means reads return the newest data or error, while availability means every request receives a response without a freshness guarantee. section 5.5

This matters more than CAP alone for databases expected to remain online most of the time: normal-operation latency is also part of the design choice. PostgreSQL replication uses independent, shared-nothing instances for redundancy and high availability, so attempts to make every node writable must account for those tradeoffs rather than assume shared storage behavior. section 5.5

Treat a homemade multi-master design as a compromise to make explicit:

  • Do not expect simultaneous writes on independent nodes to provide both low latency and full consistency without cost. section 5.5
  • Account for conflicts and distributed serialization anomalies, not only successful replication in simple tests. section 5.7
  • Prefer an established multi-master solution when the use case genuinely requires one; narrowly scoped homemade distributed systems remain safer than general-purpose reinvention. section 5.7

A replicated ticket table exposes coordination costs

A two-way logical-replication setup can initially copy and exchange ticket rows, yet independent identity values can collide: an insert fails with a duplicate primary-key error. Schema divergence can also stop a replication worker when the target lacks a replicated column. These are concrete reasons that bidirectional replication is more complex than it first appears. section 5.5 section 5.7

INSERT INTO support.tickets (content) VALUES ('fourth');
ERROR:  duplicate key value violates unique constraint "tickets_pkey"
DETAIL:  Key (id)=(1) already exists.

The failed insert shows an immediate primary-key collision after independent writes, illustrating why replicated multi-writer systems require deliberate conflict handling. section 5.5

How PostgreSQL Mistakes and How to Avoid Them covers it

How deep it goes
Defines PACELC guarantees and relates them to replication, while deferring a complete production multi-master design.
Examples
Uses a bidirectionally replicated ticket table with duplicate identity keys and a missing replicated column.
What it assumes
Assumes familiarity with PostgreSQL replication and distributed database operation rather than teaching them from zero.
What you can do after
Evaluate/understand why multi-master PostgreSQL designs require explicit compromises and established solutions for production use.
How it connects
Connects PACELC to CAP theorem, PostgreSQL logical replication, multi-master replication, and distributed serialization anomalies.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of PostgreSQL Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.