foundations

ACID and BASE

10 min read

Fully authored

Two philosophies of correctness under contention.

In 1983, Theo Härder and Andreas Reuter coined the acronym ACID — Atomicity, Consistency, Isolation, Durability. It became the manifesto of the relational database. For 25 years, if you cared about correctness, you picked an ACID database. If you didn't, you picked... nothing else, really. There were no other choices.

In 2000, Eric Brewer at UC Berkeley proposed the CAP theorem. In 2008, Brewer's colleagues at Amazon (Werner Vogels) and Google formalized BASE — Basically Available, Soft state, Eventual consistency. BASE was the manifesto of NoSQL. Not "correctness doesn't matter" — but "strong correctness costs too much at global scale; here's a different set of guarantees."

Both frameworks are still relevant. ACID never went away — it just stopped being the only option. Modern systems freely mix both: use Postgres (ACID) for orders and payments; use Redis (BASE) for the leaderboard; use CockroachDB (ACID + distributed) for the multi-region user table. The interesting question isn't "ACID or BASE?" — it's "which parts of my data need ACID, and which are fine with BASE?"

The papers

Härder & Reuter (1983) — "Principles of Transaction-Oriented Database Recovery." ACM Computing Surveys. Formalized ACID.
Brewer (2000) — PODC keynote proposing CAP. Formal proof by Gilbert & Lynch (2002).
Vogels (2008) — "Eventually Consistent." ACM Queue. Werner Vogels (Amazon CTO) popularized BASE.

ACID — the four letters

AAtomicity

All or nothing. Either the entire transaction succeeds or none of it does. No partial updates.

Example: Transfer $100: subtract from Alice AND add to Bob, or neither.

CConsistency

Invariants preserved. If constraints hold before, they hold after. Foreign keys, CHECK constraints, unique keys.

Example: Balance can't go negative. Unique username. Referential integrity.

IIsolation

Concurrent transactions don't interfere. See the Isolation Levels page for depth.

Example: Two people book the last hotel room — only one succeeds.

DDurability

Once committed, survives crashes. Written to WAL on disk before ACK.

Example: Data survives power loss, crash, restart. fsync guarantees.

BASE — the alternative

BABasically Available

The system always responds. Availability > correctness. Occasional stale data is fine.

Example: Cart shows the item — even if replica hasn't caught up yet.

SSoft state

State can change without input (via async replication). Doesn't wait for consistency.

Example: Follower count updates on its own as new replica syncs arrive.

EEventual consistency

Given no new writes, all replicas will converge. Not immediately, but eventually.

Example: Post to your feed. It shows for followers within ~1 second.

Side by side — same problem, different philosophy

Dimension	ACID	BASE
Consistency	Strong (immediate, guaranteed)	Eventual (settles over seconds)
Availability during partition	Sacrificed (may refuse writes)	Preserved (always accepts writes)
Latency	Higher (waits for locks / consensus)	Lower (async, no waiting)
Scale	Vertical scale first, distributed hard	Horizontal scale easy
Data model	Usually relational	Usually schemaless (docs, KV, columns)
Transactions	First-class, multi-row	Rare, usually single-row
Best fit	Money, identity, orders, inventory	Feeds, sessions, analytics, caches
Real users	Postgres, MySQL, Oracle, SQL Server, CockroachDB	Cassandra, DynamoDB, Redis, MongoDB (default), Riak

The false framing: "ACID = correct, BASE = broken." Wrong. BASE isn't incorrect — it makes weaker but well-defined guarantees. If your workload can tolerate temporary staleness, BASE gives you higher availability + scale for the same money.

Interactive: which philosophy for which workload?

Pick a workload — see which philosophy fits

Recommendation: ACID

Traditional banks used mainframes (ACID). Modern digital banks (N26, Chime, Revolut) increasingly on NewSQL. Distributed ACID lets them scale globally without losing bookkeeping guarantees.

Read the deep dive →

Key takeaways

ACID = transactional guarantees on one database: atomic, consistent, isolated, durable. Härder & Reuter 1983.
BASE = distributed alternative: basically available, soft state, eventual consistency. Vogels 2008.
Both frameworks are valid. Neither is "better." They target different workloads.
ACID for anything that's money, identity, or irreversible. Payments, orders, user accounts.
BASE for anything that scales huge and tolerates staleness. Feeds, activity, analytics, caches.
Most serious apps run polyglot persistence: Postgres (ACID) + Cassandra/Dynamo (BASE) + Redis (cache, BASE).
NewSQL (Spanner, CockroachDB) gives you distributed ACID — the modern answer when you need both.

References

Härder & Reuter (1983) — ACID.
Brewer (2000) — CAP theorem.
Vogels (2008) — Eventually Consistent.
Kleppmann (2017) — DDIA, Chapters 7 and 9.

Practice what you just read

Every foundation concept has a companion quiz to close the loop.

Take the URL Shortener quiz Open the flagship problem

More in foundations

Requirements → Scale → Bottleneck → Solution CAP and PACELC — the trade-off you can't avoid Back-of-the-envelope: from DAU to peak RPS Scalability — horizontal vs vertical Availability — the nines and their cost