ACID vs BASE

Two Models for Data Consistency

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 — strong consistency guarantees, used by relational databases
• BASE — relaxed consistency for availability and performance, used by many NoSQL databases

ACID

ACID stands for Atomicity, Consistency, Isolation, Durability. These are the four properties that guarantee reliable database transactions.

Atomicity

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.

Consistency

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 500

Isolation

Concurrent 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

Durability

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

BASE stands for Basically Available, Soft state, Eventually consistent. It's the model used by most distributed NoSQL databases.

Basically Available

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.

Soft State

The state of the system may change over time even without new input — because of eventual consistency propagating updates across nodes.

Eventually Consistent

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

ACID vs BASE Side by Side

When to Use ACID

Use ACID when correctness is non-negotiable:

• Financial transactions — money must not be created or destroyed
• Inventory management — can't oversell items
• Order processing — order state must be consistent
• User authentication — account creation must be atomic

Databases: PostgreSQL, MySQL, Oracle, SQL Server, SQLite

When to Use BASE

Use BASE when availability and scale matter more than perfect consistency:

• Social media feeds — slightly stale feed is acceptable
• Product catalogs — showing a slightly old price for a few seconds is fine
• User activity tracking — eventual consistency is fine for analytics
• Shopping carts — can reconcile on checkout
• DNS — propagation takes time, that's expected

Databases: Cassandra, DynamoDB, MongoDB (default), CouchDB, Redis

The Middle Ground

Many modern systems use both:

• PostgreSQL for transactional data (orders, payments, users)
• Redis for caching (BASE — eventual consistency acceptable)
• Elasticsearch for search (BASE — index lag is acceptable)
• Cassandra for time-series/activity data (BASE — scale matters)

This is called polyglot persistence — using the right database for each use case.

Key Takeaway

• ACID = strong guarantees, correctness first, harder to scale
• BASE = availability first, eventual consistency, scales easily
• The choice is driven by your data's consistency requirements
• Most real systems use both — ACID for critical data, BASE for everything else