The CAP theorem gets cited constantly and explains surprisingly little about day-to-day database behavior, because it only describes what happens during a network partition, a relatively rare event for most systems. PACELC, proposed by Daniel Abadi in 2010, fixes that gap by adding the condition that actually matters most of the time: else, when there is no partition, every distributed system still has to choose between latency and consistency. The full statement is: if partitioned, trade off availability against consistency; else, trade off latency against consistency. That second half is where your database spends nearly all of its operating life.
How it works
Break down the acronym directly:
P A C E L C
if Partitioned: Availability vs Consistency
Else: Latency vs Consistency
- PA/EL systems prioritize availability during a partition and low latency the rest of the time, accepting weaker consistency both ways. Cassandra and DynamoDB, in their default configurations, are the textbook examples.
- PC/EC systems prioritize consistency during a partition and consistency during normal operation too, accepting higher latency, such as waiting for a quorum or a single writer, as the cost. Traditional relational database replication and MongoDB under majority write and read concern lean this way.
- Mixed configurations exist and are common. Many systems let you tune the else behavior per query, such as choosing a consistency level per read, which is exactly the flexibility PACELC's framing is built to describe.
Why CAP alone falls short
CAP says: during a partition, pick availability or consistency, since you cannot have both, and partition tolerance is not optional in a real distributed system. That is a true, useful statement for the partition case specifically. But it says nothing about behavior when the network is fine, which is when your system handles the overwhelming majority of its traffic. Two systems can make the identical CAP choice, both AP, and still behave completely differently day to day, because their else branch, their normal-operation latency and consistency tradeoff, differs.
| Theorem |
Describes |
Applies |
| CAP |
Partition-time tradeoff, availability vs consistency |
Rare, only during a network partition |
| PACELC |
Partition-time and normal-time tradeoff, then latency vs consistency |
Always; the else branch is the common case |
Classifying real systems
| System |
Partition behavior |
Normal-operation behavior |
PACELC class |
| Cassandra (default) |
Available, eventually consistent |
Low latency, tunable per query |
PA/EL |
| DynamoDB (default) |
Available |
Low latency, eventually consistent by default |
PA/EL |
| MongoDB (majority read/write concern) |
Consistent, may reduce availability |
Higher latency for quorum acknowledgment |
PC/EC |
| Traditional single-primary RDBMS replication |
Consistent on the primary |
Waits for commit or replication, higher latency |
PC/EC |
| Google Spanner |
Consistent |
Higher latency for commit wait, strong consistency |
PC/EC, engineered to minimize the latency cost |
This is directly useful when picking between something like MongoDB and MySQL: the deeper question isn't the data model, it's which side of the latency and consistency line your replication and read or write concern settings actually put you on.
How to apply it
- Ask about the else branch first, not the partition branch. Your system spends nearly all of its time in normal operation, and that tradeoff affects every request's latency, while the partition tradeoff only fires during rare network events.
- Check whether consistency is tunable per operation. Many modern databases let you choose stronger consistency, and pay latency, for specific critical reads and writes while defaulting to fast or eventual elsewhere.
- Match the class to the actual requirement. Financial ledgers and inventory counts usually justify PC/EC's latency cost; social feeds, view counters, and caches usually don't need it and benefit from PA/EL's speed.
- Re-evaluate when you introduce cross-region replication. Latency costs from PC/EC choices scale with physical distance; a consistency setting that was cheap within one region can become expensive once replicas span continents.
Common mistakes
Choosing a database by its CAP label alone. "It's AP" or "it's CP" tells you nothing about normal-operation latency, which is what users actually feel on every request. Ask about the else branch instead.
Assuming eventual consistency means eventually, in milliseconds. The actual replication lag under a PA/EL configuration varies by system and load; measure it for your workload rather than assuming it's negligible.
Applying one consistency setting globally when the workload is mixed. Most PACELC-aware systems let you tune consistency per query; using the strictest setting everywhere pays the PC/EC latency tax even for reads that didn't need it.
Forgetting that PACELC classification depends on configuration, not just the product name. Many databases can be tuned toward either class depending on read and write concern settings; the product name alone doesn't fix its PACELC behavior.
FAQ
Is PACELC a replacement for CAP?
It's an extension, not a replacement. CAP's partition-time statement still holds; PACELC adds the normal-operation tradeoff that CAP is silent on.
What does the EL side actually cost in practice?
Lower latency at the cost of potentially reading stale data; a replica might answer instantly with a value that hasn't caught up to the latest write yet.
Can a system be PA/EC or PC/EL?
In principle all four combinations are namable, but PA/EL and PC/EC are far more common in practice, since most architectures make a broadly consistent latency and consistency philosophy rather than mixing opposite priorities across the two branches.
How does this relate to consensus algorithms?
Systems built on consensus algorithms, such as Raft, typically land PC/EC by construction, since a quorum write is exactly what buys consistency at the cost of latency in the else branch.
Where to go next