ACID vs BASE: Two Philosophies for Data Under Pressure
Foundations Series
| # | Post | What it covers |
|---|---|---|
| 00 | Intro | What the Foundations pillar covers and why it matters |
| 01 | Availability | Uptime, the nines, and why 99% isn't good enough |
| 02 | Reliability | Correctness over time — when uptime isn't enough |
| 03 | Latency vs Throughput vs Bandwidth | The three numbers that define system performance |
| 04 | ACID vs BASE ← you are here | Two philosophies for handling data under pressure |
| 05 | CAP Theorem | The impossibility result every distributed system runs into |
| 06 | PACELC Theorem | What CAP doesn't tell you about latency |
| 07 | Consistency Models | The spectrum from "always correct" to "eventually correct" |
| 08 | Single Point of Failure | Why one weak link breaks the whole chain |
| 09 | High Availability vs Fault Tolerance | Similar goals, very different strategies |
| 10 | Wrap-up | How all nine concepts connect |
ACID vs BASE: Two Philosophies for Data Under Pressure
The problem
It's the Friday before a long weekend. Your e-commerce platform is running a flash sale. Write load is ten times normal. Somewhere in the stack, a database node starts struggling — connections are backing up, query times are climbing.
Now your system faces a choice it was always going to face eventually: when the database is under pressure and can't do everything at once, what does it sacrifice?
Does it slow down and refuse requests rather than risk serving stale data? Or does it keep responding, accepting that some reads might be slightly out of date?
That choice — correctness under pressure vs availability under pressure — is what ACID and BASE are actually about. It's not a feature you toggle. It's a fundamental design philosophy baked into your database before you write a single line of application code.
The core idea
ACID is a set of properties that guarantee database transactions are processed reliably, prioritising correctness above everything else. BASE is an alternative set of properties that prioritise availability and partition tolerance, accepting that consistency may be temporarily sacrificed to keep the system responding.
They are not competitors in the same category. They're different answers to the same question: when your system is under stress and something has to give, what gives?
The analogy: a bank vault vs a whiteboard
ACID is a bank vault. Every deposit or withdrawal is logged, verified, and permanently recorded before anyone is told it succeeded. The process is slower — you can't just grab cash from the vault; there's a procedure. But when the transaction is done, it is done. No ambiguity, no "check back later," no chance the record disappears.
BASE is a shared whiteboard in a busy office. Fast, collaborative, always available — anyone can write on it immediately. But it's possible that two people updated the same section at the same time and one change overwrote the other. It's possible a remote colleague's version doesn't match yours yet. Someone will sync everything up eventually — but right now, different people might be looking at slightly different versions of the truth.
The whiteboard isn't broken. For many things — brainstorming, task lists, quick notes — it's exactly the right tool. You wouldn't use it to track your bank balance.
How ACID works
ACID stands for four properties that traditional relational databases (PostgreSQL, MySQL, Oracle, SQL Server) guarantee for every transaction:
Atomicity
A transaction is all-or-nothing. If you're transferring £500 from account A to account B, that's two operations: debit A, credit B. Atomicity guarantees that either both happen or neither does. If the system crashes between the debit and the credit, the debit is rolled back. There is no world where A is debited and B is never credited.
BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 500 WHERE id = 'A';
UPDATE accounts SET balance = balance + 500 WHERE id = 'B';
COMMIT;
-- If anything fails between BEGIN and COMMIT,
-- the entire transaction is rolled back automatically.
Consistency
Every transaction takes the database from one valid state to another valid state. The rules you've defined — foreign key constraints, unique constraints, check constraints — are enforced on every write. A transaction that would violate any constraint is rejected entirely.
Isolation
Concurrent transactions don't interfere with each other. If two transactions are running simultaneously, each one sees the database as if it's the only transaction running. The results are the same as if the transactions had run sequentially. (Different isolation levels offer different degrees of this guarantee — serialisable being the strongest, read committed being more common in practice.)
Durability
Once a transaction is committed, it stays committed. A server crash, a power failure, a network blip after the commit confirmation — none of these can undo a committed transaction. The data is written to persistent storage and will survive.
Together these four properties mean you can write application code that trusts the database completely. If the COMMIT returned success, the data is there. If something went wrong, the transaction was rolled back and the database is in exactly the state it was before.
The cost: ACID guarantees are expensive. Enforcing them requires locking, write-ahead logging, coordination between nodes, and — in distributed databases — consensus protocols. All of that adds latency and limits throughput.
How BASE works
BASE stands for Basically Available, Soft state, Eventually consistent — a term coined by Eric Brewer (the same person behind CAP Theorem) to describe the behaviour of large-scale distributed systems like early Amazon and eBay.
Basically Available
The system guarantees a response to every request — but that response might not reflect the most recent state of the data. Rather than refusing requests or waiting for all nodes to agree, a BASE system keeps responding, accepting the risk of temporarily serving stale data.
Soft State
The state of the system can change over time even without new input — because consistency updates are propagating across nodes in the background. At any given moment, different nodes may hold different versions of the same data. The state is "soft" in the sense that it isn't guaranteed to be stable between reads.
Eventually Consistent
Given enough time with no new updates, all nodes will converge to the same value. "Eventually" is doing a lot of work in that sentence — it typically means milliseconds to seconds in practice, but the guarantee is weaker than ACID's immediate consistency. There is a window during which different clients can read different values for the same key.
The benefit: BASE systems can be highly available, horizontally scalable, and extremely fast — because they're not waiting for global agreement before acknowledging writes. DynamoDB, Cassandra, CouchDB, and many other NoSQL databases are designed around BASE principles.
Side by side
| Property | ACID | BASE |
|---|---|---|
| Priority | Correctness | Availability |
| Consistency | Immediate, guaranteed | Eventual |
| Transaction model | All-or-nothing | Best-effort |
| State | Hard (stable between reads) | Soft (may change without new input) |
| Under partition | May reject requests to stay consistent | Keeps responding, reconciles later |
| Performance | Lower write throughput, higher latency | Higher write throughput, lower latency |
| Typical databases | PostgreSQL, MySQL, Oracle, SQL Server | Cassandra, DynamoDB, CouchDB, Riak |
| Best for | Financial data, medical records, anything where correctness is non-negotiable | User activity feeds, shopping carts, metrics, anything tolerant of brief staleness |
The tradeoffs
ACID's hidden costs. Locking is the most common performance killer in ACID systems. When a transaction holds a lock on a row, every other transaction that needs that row must wait. Under high write concurrency, lock contention can become the dominant bottleneck — causing exactly the kind of degradation that BASE systems avoid. ACID also makes horizontal scaling genuinely hard: coordinating transactions across multiple nodes requires distributed consensus, which is expensive.
BASE's hidden risks. "Eventually consistent" requires you to reason carefully about the consistency window. What happens in your application when a user writes data and then immediately reads it back — and the read hits a node that hasn't received the write yet? What happens when two clients update the same record simultaneously on different nodes? BASE systems push these questions up to the application layer, where they're harder to reason about than database constraints.
The false binary. Modern databases blur this line. PostgreSQL offers tunable isolation levels. DynamoDB offers optional strongly consistent reads at higher cost. CockroachDB and Spanner provide ACID guarantees in distributed systems using consensus protocols. The ACID/BASE framing is most useful as a way to reason about default behaviour and design philosophy — not as a permanent constraint on what any specific database can do.
When to reach for each
Reach for ACID when:
Money is involved in any way — payments, transfers, credits, billing
Data integrity failures have real-world consequences (medical records, legal documents, inventory counts)
Your application relies on constraints being enforced (referential integrity, uniqueness guarantees)
You need transactions across multiple rows or tables
Reach for BASE when:
Write throughput is more important than immediate consistency
Horizontal scalability is a hard requirement
Brief staleness is acceptable (a social media feed being 500ms behind is fine; a bank balance being 500ms behind is not)
You're storing append-mostly data where conflicts are rare or resolvable — user events, logs, metrics, recommendations
A practical note: most production systems use both. The payments service uses PostgreSQL with full ACID guarantees. The user activity feed uses DynamoDB with BASE semantics. The recommendation engine uses Cassandra. The art is knowing which data has which consistency requirements — and matching the database to the need rather than picking one database for everything.
The one thing to remember
ACID and BASE are not database features you configure — they're commitments your database makes about what happens when things go wrong. Before you choose a database, define what "wrong" looks like for your data: is it worse to return stale data, or to refuse to respond at all? Answer that question first. The database choice follows naturally.
← Previous: Latency vs Throughput vs Bandwidth — how fast data moves through your system
→ Next: CAP Theorem — ACID and BASE describe what a single database prioritises; CAP Theorem describes the fundamental limit that all distributed systems run into, and why you can never fully escape the tradeoff between consistency and availability.
