CAP is insufficient; PACELC adds the normal-operation trade-off

heuristic
established
no code

Scope. PACELC is a design taxonomy, not a theorem: it proves nothing and classifies the trade-offs a system makes in and out of a partition. “A CP/AP database” is a marketing label, because real systems are tuned per operation.

Conflicts with: Linearizability ↔ latency/availability (PACELC)

Primary sources: Daniel Abadi — Consistency Tradeoffs in Modern Distributed Database System Design (PACELC), IEEE Computer, 2012

Other claims on this card, typed separately:

- theorem
- established
CAP is a theorem only in the Gilbert–Lynch model: an asynchronous network that may lose messages, an atomic read/write register, and the requirement that every request to a non-failed node gets a response. Outside those premises it is not a proof about your database.
Primary sources: Gilbert, Lynch — Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services, ACM SIGACT News, 2002, Gilbert, Lynch — Perspectives on the CAP Theorem, IEEE Computer, 2012
- author’s position
- opinionated
The consistency level is a property of the operation, not of the system, and is chosen by the invariant the operation protects.

CAP in its popular form is degenerate: P is not a choice — partitions happen, and the only choice is between C and A during a partition. PACELC is more honest: even without a partition (E), a choice between latency (L) and consistency (C) always exists — synchronous replication costs an RTT on every write.

CAP began as Eric Brewer’s conjecture in his PODC 2000 keynote and was proved by Seth Gilbert and Nancy Lynch (SIGACT News, 2002) for a precise model: C there means linearizability, A means every request to a non-failed node gets a response, and the proof is about behaviour while messages are lost. Brewer himself revisited it in “CAP Twelve Years Later: How the ‘Rules’ Have Changed” (IEEE Computer, 2012), stressing that partitions are rare and the choice is made per operation. PACELC is Daniel Abadi’s, from “Consistency Tradeoffs in Modern Distributed Database System Design” (IEEE Computer, 2012): if there is a Partition, choose A or C; Else, choose Latency or Consistency. In his classification the default configurations of Dynamo-style stores are PA/EL, and fully ACID systems are PC/EC.

Honest assessment. “CP or AP” as a database label is a marketing taxonomy; real systems are tuned per operation (quorum vs one in Cassandra, synchronous_commit in Postgres). The principle: the consistency level is a property of the operation, not of the system, and it is chosen by the invariant the operation protects.

PACELC does not invalidate CAP, it extends it: CAP describes behavior during a partition, PACELC adds the choice in normal operation. The “insufficient” in the title refers to the popular use of CAP as a label for databases. And synchronous_commit in PostgreSQL is a commit-acknowledgment and durability/replication setting, not a per-operation consistency-model switch.

The EL/EC choice in numbers. A PostgreSQL primary with a synchronous standby in another availability zone waits for the standby on every commit: about a millisecond or two inside a region, tens of milliseconds to another region. Asynchronous replication removes that wait and opens a window in which an acknowledged write exists on one machine only. Neither is “the right setting”; the invariant decides (65, 90) — a payment ledger pays the RTT, a view counter does not.