ACID vs BASE Properties

ACID and BASE are two answers to the same mechanical problem — how a database keeps data correct while machines crash and requests race — where ACID force-orders every write through a durable log plus locks (or versioning) so a commit lands atomically and becomes visible everywhere at once, and BASE lets independent replicas accept writes and reconcile them afterward so the system never stops answering.

They are not good-vs-bad; they are different placements of one dial: who pays for consistency, and when. ACID makes the database pay it up front (locks, coordination, latency) so your application code can assume the data is always correct. BASE hands that cost to you — the application must tolerate and reconcile temporary disagreement — in exchange for staying available and scaling across many machines. The rest of this page shows the machinery behind each, traces both with real numbers, corrects the usual CAP shorthand, and gives the decision rule a senior engineer actually uses.

ACID: the four guarantees and the machinery behind them

A transaction is a bundle of steps treated as one unit (transfer money, book a seat). ACID is four promises about that unit, and each is delivered by a specific mechanism — not by good intentions:

• Atomicity (all-or-nothing). Delivered by the write-ahead log: every intended change is recorded to disk before it is applied, so on a crash the engine can either replay a committed transaction or discard an unfinished one. You never get cash out of an ATM without your balance dropping, or a debit without the matching credit.
• Consistency (invariants hold). The transaction moves the database from one legal state to another — constraints, foreign keys, and rules you declared stay true. Transfer $100 between two accounts whose total is $600, and the total is still $600 afterward. Note: this is your invariants, not the distributed-systems meaning of "consistency" (see Pitfalls).
• Isolation (no interference). Delivered by locking or multi-version concurrency control (MVCC): concurrent transactions behave as if run one at a time. A reader of an inventory row sees the old count or the new count — never a half-updated in-between.
• Durability (survives failure). Once commit returns success, the change is on stable storage (the log is fsync'd). A power cut a millisecond later cannot un-send a message the app already confirmed.

The diagram below shows how one log line does most of the heavy lifting for both atomicity and durability.

Traced: a $100 transfer that survives a crash

Account A starts at $500, B at $100; the invariant is total = $600. We transfer $100 from A to B. Follow the engine step by step — the row where it becomes durable is the pivot.

Crash after step 5, before step 7: restart, engine sees the COMMIT record, REDOs it → A=400, B=200, total 600. Durability held. Crash after step 3, before step 5 (no COMMIT): restart discards the incomplete transaction → A=500, B=100, total 600. Atomicity held. The one state ACID makes impossible is A=400 with B=100 — $100 vanished. That impossibility is the guarantee, and it costs the two fsyncs and the isolation lock held across steps 1–6.

BASE: available first, consistent eventually

BASE — Basically Available, Soft state, Eventually consistent — is the philosophy of most large distributed and NoSQL stores. Instead of coordinating every write globally before answering, replicas accept writes locally and propagate them asynchronously:

• Basically Available: every request gets a response, even under load or partial failure. During a flash sale the site keeps taking orders even if an inventory count is a few seconds behind, rather than locking up.
• Soft state: the stored value may drift on its own as replication catches up, without any new client write. Different replicas can legitimately hold different values at the same instant.
• Eventually consistent: if writes stop, all replicas converge to the same value — with no promise of when. Edit a social post and a friend's app may show the old text for a few seconds before it settles.

The mechanism that buys availability is exactly what creates the anomaly window, as the next diagram traces.

Traced: one sneaker, two orders

A limited sneaker has stock = 1, replicated to two regions with last-write-wins reconciliation. Replication lag is ~200 ms.

• t0: R1 = 1, R2 = 1.
• t1 (10:00:00.100): User X checks out on R1 → R1 sets stock = 0. R2 hasn't received the update yet — soft state.
• t2 (10:00:00.180): User Y, routed to R2, reads stock = 1 and checks out. Both regions have now accepted an order for the same unit — an oversell the database did not prevent.
• t3 (10:00:00.300): replication settles; both replicas read stock = 0. The data is now consistent — but two paid orders exist for one item.

Nothing here is a bug in the store; it did exactly what BASE promises. The oversell is the application's problem to reconcile (cancel-and-refund, backorder, or gate the checkout through a strongly-consistent counter). That relocation of the correctness burden from the database to your code is the true price of BASE — and it is easy to under-budget.

CAP, stated correctly (not "pick two of three")

The popular slogan — a distributed system can guarantee only two of Consistency, Availability, and Partition tolerance — is misleading, and it is the one thing worth unlearning here. In any real system spanning more than one machine, network partitions are not optional: packets drop, links flap, nodes hang. So P is a fact of the environment, not a feature you trade away. That collapses the "three-way" choice into a much sharper one:

• When there is no partition, a well-built system can be both consistent and available. No trade is forced.
• Only during a partition does the choice bite: a node cut off from its peers must either refuse the request to avoid serving/accepting divergent data (choosing Consistency → CP), or answer anyway with possibly stale data (choosing Availability → AP).

ACID / strong-consistency stores lean CP; BASE stores lean AP. And even outside partitions the story continues — PACELC completes it: if Partitioned, choose A or C; Else, choose Latency or Consistency. Synchronous replication for strong reads costs latency on every request, partition or not. So the honest framing is: C-vs-A only under partition, L-vs-C the rest of the time.

ACID vs BASE — the trade-off at a glance

When to use ACID, when to use BASE

Decide per operation, not per company. The signal is the cost of a wrong or stale read.

Reach for ACID when a stale or partial read has real-world consequences that are expensive to unwind: money movement, ledgers, inventory decrements that must not oversell, seat/booking allocation, auth and permission changes, anything with an invariant a regulator or an angry customer will check. Concrete signals: "double-spend is unacceptable," "the two writes must both happen or neither," "we need to read our own write immediately," bounded data volume that fits a primary + read replicas.

Reach for BASE when availability and scale dominate and a few seconds of staleness is invisible or cheap to reconcile: feeds, timelines, likes/view counts, product catalogs, sessions, telemetry, notifications, caches. Signals: "the site must never go down globally," "we serve millions of reads across regions," "a like showing up a second late is fine," write volume that no single node can absorb.

Choose ACID (e.g. PostgreSQL, a single-region relational store) when correctness on every read is the product and you can scale by sharding a bounded working set. Prefer BASE (e.g. Cassandra, DynamoDB) when you would rather serve slightly stale data than serve an error, and you are prepared to write the reconciliation logic. The mature answer is usually both: the money path on ACID, the read-heavy experience on BASE — and where the store allows it, turn the dial per query (Cassandra/DynamoDB quorum reads, Mongo majority writes, Postgres synchronous replicas). ACID vs BASE is a spectrum with a knob, not a binary.

Pitfalls

• Conflating ACID's "C" with CAP's "C." They are different words that happen to share a letter. ACID Consistency = your declared invariants and constraints hold after a transaction. CAP Consistency = every read across all nodes reflects the latest write (linearizability). A single-node ACID database is fully ACID-consistent yet says nothing about CAP consistency across replicas.
• Assuming "SQL = ACID" automatically. MySQL's MyISAM engine is not transactional; only InnoDB is. And even on an ACID engine the default isolation level (often READ COMMITTED or REPEATABLE READ, not SERIALIZABLE) still permits anomalies like write skew and phantoms — you have to opt into full serializability, and pay for it.
• Trusting last-write-wins in BASE. LWW silently discards one of two concurrent updates — a lost update no error ever surfaces. If both writes matter, you need version vectors, CRDTs, or explicit application merge, not a timestamp comparison.
• Forgetting session guarantees. Plain eventual consistency can violate read-your-own-writes and monotonic reads: a user posts, refreshes, and their post is gone (routed to a lagging replica). Fix with sticky sessions, read-from-leader for that user, or causal consistency.
• Treating BASE as "no consistency at all." Modern AP stores are tunable — quorum reads/writes, causal or bounded-staleness modes, per-key transactions. Leaving them at the loosest setting throws away reliability you already paid for.
• Believing distributed ACID scales like single-node ACID. Two-phase commit adds round trips and, worse, blocks if the coordinator dies mid-commit. Cross-shard ACID is a real cost, not a free upgrade — many teams shard to keep each transaction on one node precisely to avoid it.

Real systems on each side

• ACID-leaning: PostgreSQL, MySQL/InnoDB, Oracle, SQL Server, SQLite for the classic relational world; newer distributed-SQL stores (Google Spanner, CockroachDB, YugabyteDB) provide ACID across nodes using synchronized clocks or consensus — at a latency cost. Even document stores now offer it: MongoDB supports multi-document ACID transactions.
• BASE-leaning: Apache Cassandra, Amazon DynamoDB, Riak, Couchbase, and Redis (default async replication) are built to stay available and scale horizontally, with eventual — often tunable — consistency. Netflix and Apple run Cassandra across data centers for exactly this reason.

The line is blurring: Dynamo and Cassandra let you request stronger reads per query, and Spanner/Cockroach let you relax where you don't need strictness. "ACID or BASE" increasingly means "which end of the dial is this operation's default."

Takeaways

• ACID's guarantees are delivered by concrete machinery — WAL for atomicity + durability, locks or MVCC for isolation, constraint checks for consistency — cheap on one node, expensive (2PC) across many.
• BASE buys availability and scale by letting replicas accept writes and reconcile later; it doesn't remove the correctness cost, it moves it into your application.
• CAP is not "pick two of three." Partitions are unavoidable, so the forced choice is C-vs-A only during a partition; PACELC's "else" reminds you it's latency-vs-consistency the rest of the time.
• It's a dial, not a switch: put money on ACID, feeds on BASE, and use tunable consistency per operation where the store offers it.

Re-authored and deepened for this guide. Sources: Härder & Reuter, "Principles of Transaction-Oriented Database Recovery" (1983, which coined ACID); Gray & Reuter, Transaction Processing: Concepts and Techniques; Eric Brewer's CAP conjecture (PODC 2000) and "CAP Twelve Years Later" (IEEE Computer, 2012); Daniel Abadi's PACELC formulation (2012); Dan Pritchett, "BASE: An Acid Alternative" (ACM Queue, 2008); DeCandia et al., "Dynamo: Amazon's Highly Available Key-value Store" (SOSP 2007); Martin Kleppmann, Designing Data-Intensive Applications; and the PostgreSQL, MySQL/InnoDB, Cassandra, and DynamoDB documentation.