laranevans.com
Topics / Distributed Systems / PACELC

PACELC

pillar/systems topic/distributed-systems topic/databases topic/consistency evolving reviewed 2026-05-31

PACELC is a design principle for replicated data stores. Daniel Abadi introduced it in a 2010 post on his DBMS Musings blog and formalized it in the 2012 IEEE Computer article Consistency Tradeoffs in Modern Distributed Database System Design. Read it as one question with two branches. If there is a partition (P), does the system trade availability (A) for consistency (C)? Else (E), in normal operation, does it trade latency (L) for consistency (C)? Abadi pronounces the acronym "pass-elk."

PACELC completes the CAP theorem. CAP, conjectured by Eric Brewer and proven by Seth Gilbert and Nancy Lynch in 2002, says a data store facing a network partition provides at most two of consistency, availability, and partition tolerance. CAP describes one regime, the partition. Abadi reframes the concern: CAP "only posits limitations in the face of certain types of failures, and does not constrain any system capabilities during normal operation." A partition is rare. Normal operation is everything else. PACELC keeps the partition branch and adds the branch a replicated system runs in nearly all of the time.

Consistency and latency trade off because replication takes coordination

A replicated store keeps copies of each record on several nodes. Keeping those copies in agreement forces a choice the moment a write arrives.

Option A: Send the update to every replica synchronously and the write waits for the slowest replica before it returns. This option provides consistency by sacrificing latency at write-time. Option B: Route every read and write through a master and the request travels to the master's location even when a nearer replica holds the data. This option provides consistency by sacrificing latency at read-time. Option C: Accept a write at any replica and answer right away, and two replicas take conflicting updates that reconcile later, so a reader sees stale or divergent data. This option provides low-latency at the expense of (eventual) consistency.

Each option buys latency with consistency, or consistency with latency.

The partition choice and the normal-operation choice are independent

A store's behavior under a partition does not predict its behavior under normal operating conditions (no partitions). The two letters move on their own, which produces four quadrants. Abadi places well-known systems across all of them in the 2012 article and the original blog post:

System PACELC Under a partition In normal operation
Dynamo, Cassandra, Riak PA/EL availability over consistency latency over consistency
Fully ACID stores (VoltDB/H-Store, Megastore, HBase) PC/EC consistency over availability consistency over latency
PNUTS PC/EL consistency over availability latency over consistency
MongoDB PA/EC availability over consistency consistency over latency

PNUTS reads as the instructive case. In normal operation it serves low-latency reads from any replica and accepts stale data, an EL choice. Under a partition it holds its baseline consistency and drops availability instead, a PC choice. MongoDB runs the opposite pattern: consistent reads and writes through a primary in normal operation (EC), and a failover that leaves the old and new primary briefly divergent under a partition (PA). The "PC" label carries a caveat Abadi states directly. It does not mean fully consistent. It means a partition does not reduce consistency below the system's normal-operation baseline.

The consistency knob is set per operation, not per system

The table labels default configurations. Every system in it exposes the choice as a parameter. Cassandra sets a consistency level per query. DynamoDB picks a strong or eventual read per call. A quorum store tunes the read set R and the write set W against the replica count N, and a configuration where R + W > N guarantees a read overlaps the latest write. Raising R + W buys consistency and pays latency on each request.

The consequence for design: classify the operation, not the database. A shopping-cart append tolerates a stale read and wants low latency. A balance transfer wants a consistent read and accepts the round trips. One store serves both when you set its consistency per call to match what each operation needs.

The C in PACELC is not the C in ACID

Two different properties share the letter C, and treating them as one property produces confusion in design discussions. In CAP and PACELC, consistency means linearizability: every operation appears to take effect at a single instant, and a read returns the latest completed write under one global order. Gilbert and Lynch state it as "a total order on all operations such that each operation looks as if it were completed at a single instant." This is a property about the ordering and visibility of operations.

In ACID, consistency means something else: a transaction moves the database from one valid state to another, preserving invariants like foreign keys and uniqueness constraints. The closer ACID analog to CAP's consistency is isolation, not ACID's own C. Peter Bailis draws the line in Linearizability versus Serializability: linearizability is "a guarantee about single operations on single objects" and maps to the C in CAP, while serializability is "a guarantee about transactions" and is the I in ACID.

Partition tolerance is not a choice

A distributed store running across a network tolerates partitions whether its designers want to or not, because the network drops and delays messages on its own schedule. This turns the "CA" corner of CAP into a description of a system that has not yet met its first partition, rather than a design target. The real decisions are the two PACELC branches: what the system surrenders when a partition arrives, and what it surrenders the rest of the time. Treating partition tolerance as optional hides the second decision, the one that runs continuously.

Spanner pays the tradeoff down, it does not escape it

Google Spanner looks at first like a counterexample, a globally distributed store offering strong consistency and high availability at once. It is no exception to PACELC. Spanner sits in the PC/EC quadrant and pays that quadrant's price. Abadi classifies Spanner as a CP system in CAP terms, one that guarantees "100% consistency (serializability, linearizability, etc.) across the entire system". It reaches that guarantee with TrueTime, a clock API that bounds timestamp uncertainty, and a commit-wait that holds each transaction until the uncertainty window passes so commit order matches real time. Google's documentation states that "Spanner provides external consistency, which is the strictest consistency property for transaction-processing systems."

That guarantee carries the latency the EC choice predicts. Spanner pays the commit-wait on every transaction, and Abadi notes its two-phase commit runs "at least equal to three times the latency of cross-region Paxos." Tight clock synchronization and careful engineering shrink the cost and make global strong consistency practical. They do not remove it. Spanner chose consistency in both branches and pays availability under a partition and latency in normal operation, exactly as PC/EC describes.

Using PACELC in a design

PACELC does not pick a quadrant for you. It forces two questions that coarser framings let you skip: what does this system give up under a partition, and what does it give up the rest of the time? Answer both per operation, weight the Else branch because the system spends its life there, and the quadrant falls out of the requirements rather than out of a default.

Sources