ACID vs BASE

Prefer to watch? ▶ ACID vs BASE in 90 seconds ✈ Telegram

You transfer $100 and the network splits mid-write. Does the money vanish? Or does the bank refuse the transaction? That single question determines whether your database is ACID or BASE—and it's the core choice behind every system design decision.

Mental model: ACID = correctness-first (transaction is all-or-nothing, everyone sees one truth instantly); BASE = availability-first (any node answers now, replicas agree later).

The $100 Transfer: Why This Matters

Imagine you're sending $100 to a friend. The debit from your account and the credit to theirs is a single logical operation. But under the hood, it's two writes to two places. If the network partitions between those two writes, a database has to choose:

ACID's choice: "I refuse to commit this transaction until I know both the debit and credit succeeded. If I can't guarantee both or neither, I reject the write." Your $100 stays safe—no money vanishes, no double-spend—but you wait.
BASE's choice: "I'll accept your write on this node right now. I'll send it to the replicas in the background. If they disagree for a bit, that's fine—we'll converge." You get an answer instantly, but for a moment, two replicas might disagree on your balance.

Banks choose ACID. Instagram's like counter chooses BASE. Neither is wrong; they're answering different questions.

ACID: Correctness-First

ACID stands for Atomicity, Consistency, Isolation, Durability. Here's what each means in concrete terms:

Atomicity A transaction is all-or-nothing. The debit and credit both commit, or both roll back. Never one without the other.

Consistency After a transaction commits, the database is in a valid state. All constraints are met. You can't overdraw an account; the balance rule is enforced.

Isolation One transaction's in-flight work doesn't interfere with another's. Two users can't both see the same balance as available when only one $100 exists.

Durability Once a transaction commits, it's written to disk (or persistent storage). A server crash doesn't erase it.

Where you see ACID:

Postgres, MySQL, SQL Server
Banking systems, payment ledgers, order fulfillment
Inventory management, financial records
Any system where money or legal liability is involved

The cost:

Coordination overhead: Keeping one truth across machines means locking rows, waiting for consensus, and synchronous replication. This adds latency and CPU.
Scale limits: Writes across many machines require coordination. Sharding helps, but cross-shard transactions become expensive.
Partition behavior: Under a network partition (CAP theorem), ACID systems choose Consistency over Availability. They'd rather reject your write than let two replicas disagree. This is CP (Consistent, Partition-tolerant).

BASE: Availability-First

BASE stands for Basically Available, Soft state, Eventually consistent. It inverts ACID's priorities:

Basically Available Every node answers your read or write immediately. No waiting for consensus.

Soft state The data isn't guaranteed to be consistent at any instant. Replicas lag each other temporarily.

Eventually consistent Given enough time without new writes, all replicas converge to the same value.

Where you see BASE:

DynamoDB, Cassandra, Riak
Social media engagement (likes, comments, shares)
Shopping carts, recommendations
DNS, caching layers
Any system where a stale read is acceptable

The cost:

Stale reads: You might read a value that hasn't propagated yet. Two users can see 41 likes and 42 likes simultaneously for the same post. Both are temporarily true.
Inventory risk: If you oversell because replicas lag, you're overcommitted. A BASE checkout system must reconcile inventory later.
Partition behavior: Under a network partition, BASE systems choose Availability over Consistency. They serve requests from each partition, accepting that they'll diverge. This is AP (Available, Partition-tolerant).

Side-by-Side: When to Choose Each

Dimension	ACID	BASE
Immediate correctness	Guaranteed. All replicas agree after commit.	Not guaranteed. Replicas may lag.
Read latency	Higher. Must check consistency guarantees.	Lower. Any replica answers immediately.
Write latency	Higher. Coordination, locking, sync replication.	Lower. Local write, async propagation.
Write scale	Harder. Cross-machine transactions are expensive.	Easier. Each node can write independently.
Network partition behavior	Rejects writes (CP).	Accepts writes, reconciles later (AP).
Stale read risk	Minimal or zero.	Present and expected.
Data loss risk	Very low (durability guarantees).	Possible (eventual consistency is eventual).
Example use case	Bank account, order total, inventory decrement	Like count, comment view, shopping cart

The Real World: The Line Is Blurry Now

The ACID vs. BASE split used to be sharp: relational databases were ACID, NoSQL was BASE. But the tradeoff space has matured, and the line is no longer a cliff.

DynamoDB (tunable consistency) DynamoDB is BASE by default (eventual consistency), but you can ask for a strongly consistent read on a per-request basis. This lets you cherry-pick: use eventual reads for the like count, but a strong read for inventory before checkout.

Google Spanner (ACID at scale) Spanner is a globally distributed database that achieves ACID guarantees across continents. It uses atomic clocks and careful engineering to eliminate the traditional scale penalty. But it still has higher latency than local BASE systems.

PostgreSQL 14+ (quorum reads) Postgres now supports tunable replication levels. You can ask for a read from a majority of replicas (quorum) without waiting for all, trading some consistency for lower latency.

The takeaway: choose per-data, not per-database. A single system can store money (ACID logic) and like counts (BASE logic) side-by-side, or you can use a hybrid architecture: strong consistency for critical data, eventual consistency for non-critical.

For LLM Inference: Latency and Staleness

If you're thinking about this from an LLM-serving perspective, the ACID/BASE decision maps to latency and staleness:

ACID = synchronous guarantee before returning. Wait for all replicas to agree (latency hit, but TTFT is clean).
BASE = return immediately with stale data, update asynchronously (lower TTFT, but the embedding or user context might be out-of-date).

For a chatbot using cached embeddings, BASE is fine—staleness by a few seconds doesn't break the model. For a real-time pricing engine, ACID is necessary. The decision is the same: can this data be briefly wrong?

The One-Line Verdict

Reach for ACID when the cost of wrongness is high (money, inventory, orders, ledgers). Reach for BASE when speed and availability matter more than instant correctness (engagement, recommendations, caches, counters).

The real skill is asking yourself: "Can this data be briefly wrong?" If the answer is no, ACID. If yes, BASE. If uncertain, start with ACID and move to BASE only for non-critical data.

Watch the 90-second reel for the concrete $100 transfer scenario.