ACID vs BASE
The two database philosophies — guarantee correctness with transactions, or trade it for scale and availability — and which your data demands.
Two philosophies of correctness
- ACID — the relational promise: transactions are all-or-nothing and the data is always valid. Prioritizes correctness.
- BASE — the distributed-NoSQL stance: stay available and scalable, accept temporary inconsistency. Prioritizes availability and scale.
They sit at opposite ends of the consistency/availability spectrum, and the names are a deliberate chemistry pun (acid vs base).
ACID, unpacked
- Atomicity — a transaction fully completes or fully rolls back; no partial writes.
- Consistency — every transaction moves the DB from one valid state to another (constraints hold).
- Isolation — concurrent transactions don’t see each other’s half-done work; the result equals some serial order.
- Durability — once committed, data survives crashes.
Gives you a clean mental model — you reason as if one user at a time. The cost: the coordination needed for isolation and durability is hard to scale horizontally, which is why ACID stores lean on a single primary.
BASE, unpacked
- Basically Available — the system always responds (maybe with stale data).
- Soft state — state may change over time without input, as replicas sync.
- Eventually consistent — replicas converge given time.
Gives you horizontal scale and high availability. The cost: the application must tolerate stale reads and handle conflicts, because the database won’t guarantee a single correct order for you.
Choosing
| Use ACID when… | Use BASE when… |
|---|---|
| Money, orders, inventory, bookings | Feeds, likes, views, recommendations |
| Invariants must never break | Scale/availability beat strict freshness |
| You need multi-row transactions | Data is key-addressed, write-heavy |
| Moderate scale (single primary OK) | Massive scale across regions |
The mature answer
Same as SQL vs NoSQL: use both. Put the transactional core (payments, orders) in an ACID store and the high-volume, tolerant parts (activity, metrics, sessions) in a BASE store. And note that the line has blurred — distributed SQL (Spanner, CockroachDB) offers ACID at scale, and many NoSQL stores now support limited transactions. In an interview: “the wallet balance is ACID — I can’t half-debit someone; the transaction history feed is BASE — eventual consistency is fine there.” That per-data split is the point.