ACID vs BASE: What Database Guarantees Actually Promise

When people say a database is “ACID-compliant” or “eventually consistent,” they are making promises about what happens when things go wrong — concurrent writes, crashes, network failures. ACID and BASE are the two vocabularies for those promises, and knowing the difference tells you what you can and cannot rely on.

What ACID guarantees

ACID is the contract that traditional transactional databases — PostgreSQL, MySQL/InnoDB, Oracle, SQLite — make about a transaction (a group of operations treated as one unit). The four letters:

• Atomicity: the whole transaction succeeds or none of it does. If a bank transfer debits one account but the credit fails, the debit is rolled back. There is no half-done state.
• Consistency: a committed transaction moves the database from one valid state to another, never violating its declared rules (constraints, foreign keys, types). It will not let you, say, leave a foreign key pointing at a row that does not exist.
• Isolation: concurrent transactions do not step on each other. The result is as if they ran one at a time, even when they actually ran in parallel. (In practice databases offer tunable isolation levels — from “read committed” to “serializable” — trading strictness for speed.)
• Durability: once the database says “committed,” that data survives a crash or power loss. It has been written somewhere persistent, not just held in memory.

The payoff is that you can reason about your data simply: after a successful commit, the world is exactly what you asked for. The cost is coordination, which gets expensive when data is spread across many machines.

What BASE trades away

BASE is the model many distributed and NoSQL systems adopt — think Cassandra, DynamoDB, or Riak — when they need to scale across many nodes and stay up through failures. The acronym is deliberately a chemistry pun on ACID, and it stands for:

• Basically Available: the system answers requests even during partial failures, possibly with stale or incomplete data rather than an error.
• Soft state: the data may change over time even without new writes, because the system is still reconciling replicas in the background.
• Eventual consistency: if writes stop, all replicas will eventually converge to the same value — but at any given instant, two reads from two nodes might disagree.

The trade is explicit: you give up the guarantee that every read sees the latest write, in exchange for staying available and scaling horizontally. A write to one node propagates to others after a short delay, so a reader elsewhere might briefly see the old value.

CAP, and why this is a spectrum

The deeper reason ACID and BASE exist is the CAP theorem: when a network partition splits your nodes so they cannot talk, a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response). It cannot have both while partitioned. ACID-leaning systems tend to sacrifice availability to stay correct; BASE-leaning systems stay available and let consistency lag.

Choosing a model is really choosing where your failure cost lands. A bank transfer must be ACID: showing money in two places at once, or losing a committed deposit, is unacceptable. A like counter or a social feed can be BASE: if your like count reads 1,041 on one screen and 1,042 on another for a second, nobody is harmed, and staying fast and available matters far more.

-- ACID: the classic all-or-nothing transfer
BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;  -- both happen, or neither does

FAQ

Eventual consistency sounds risky, but for the right workloads it is the correct engineering choice — the cost of a stale read is trivial, and the benefit in availability and scale is large.