ACID and BASE are two opposing models for database transactions. Learn what each guarantees, where they apply, and how to choose between them.
When designing systems that store data, you need to decide how strictly the database enforces consistency. Two models sit at opposite ends of the spectrum:
ACID stands for Atomicity, Consistency, Isolation, Durability. These are the four properties that guarantee reliable database transactions.
A transaction is all-or-nothing. Either all operations in the transaction succeed, or none of them do.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- debit
UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- credit
COMMIT;If the second UPDATE fails, the first is rolled back. You never end up with money debited but not credited.
A transaction brings the database from one valid state to another. All defined rules (constraints, cascades, triggers) are enforced.
-- This will fail if balance goes negative (constraint violation)
UPDATE accounts SET balance = balance - 1000 WHERE id = 1;
-- balance was 500, constraint: balance >= 0
-- Transaction rolls back, balance stays at 500Concurrent transactions execute as if they were sequential. One transaction's intermediate state is not visible to others.
Transaction A: reads balance (500), deducts 100
Transaction B: reads balance (500), deducts 200
Without isolation: both see 500, both succeed → balance ends at 300 (should be 200)
With isolation: B waits for A to commit → sees 400, deducts 200 → balance = 200 ✓
Isolation levels (weakest to strongest): Read Uncommitted → Read Committed → Repeatable Read → Serializable
Once a transaction is committed, it stays committed — even if the system crashes immediately after.
Achieved through write-ahead logs (WAL) — changes are written to disk before the commit is acknowledged.
BASE stands for Basically Available, Soft state, Eventually consistent. It's the model used by most distributed NoSQL databases.
The system guarantees availability — every request gets a response, even if some nodes are down. The response might be stale or partial, but the system stays up.
The state of the system may change over time even without new input — because of eventual consistency propagating updates across nodes.
Given enough time with no new updates, all replicas will converge to the same value. There's no guarantee of when — just that it will happen.
User updates profile photo on Node A
→ Node A acknowledges immediately
→ Node B still shows old photo (for a few seconds)
→ Replication catches up
→ Node B now shows new photo
| Property | ACID | BASE |
|---|---|---|
| Consistency | Strong, immediate | Eventual |
| Availability | May sacrifice for consistency | Prioritized |
| Performance | Lower (coordination overhead) | Higher (local writes) |
| Complexity | Simpler to reason about | Harder to reason about |
| Scalability | Harder to scale horizontally | Designed for horizontal scale |
| Use case | Financial, transactional | Social, analytics, high-scale |
Use ACID when correctness is non-negotiable:
Databases: PostgreSQL, MySQL, Oracle, SQL Server, SQLite
Use BASE when availability and scale matter more than perfect consistency:
Databases: Cassandra, DynamoDB, MongoDB (default), CouchDB, Redis
Many modern systems use both:
This is called polyglot persistence — using the right database for each use case.