ACID vs BASE
Strong consistency (relational) vs eventual consistency (distributed)
ACID (Atomicity, Consistency, Isolation, Durability) is the transaction model of traditional relational databases — guaranteeing that a set of operations either all succeed or all fail, with no partial or inconsistent states ever visible. BASE (Basically Available, Soft state, Eventual consistency) is the alternative model adopted by most distributed NoSQL systems — prioritizing availability and partition tolerance over strong consistency, accepting that replicas may temporarily diverge. The choice between ACID and BASE is not a moral one; it is a function of business requirements — financial ledgers require ACID; social media feeds tolerate BASE. Modern systems often use both: an ACID relational store for financial state and a BASE distributed cache for user feeds.
Key Points
- Atomicity: all operations in a transaction succeed or all are rolled back — prevents the "charge without delivery" failure mode that destroys user trust.
- Consistency (ACID): transactions take the database from one valid state to another, enforcing all constraints (foreign keys, uniqueness, check constraints) — distinct from CAP's "C".
- Isolation levels (weakest to strongest): Read Uncommitted → Read Committed → Repeatable Read → Serializable — higher isolation prevents more anomalies at higher performance cost.
- Durability: committed transactions survive crashes — implemented via write-ahead logs (WAL) in PostgreSQL, redo logs in MySQL InnoDB, and journaling in most ACID systems.
- BASE eventual consistency models: causal consistency (respects cause-effect ordering), session consistency (consistent within one session), monotonic read (never see older data twice).
- Distributed ACID is achievable via 2-Phase Commit (2PC) or distributed consensus (Raft/Paxos) but at significant latency cost — Google Spanner is the production gold standard.
- NewSQL (CockroachDB, TiDB, YugabyteDB) provides ACID semantics with horizontal scalability using Raft consensus — bridging the ACID/BASE divide.
- Saga pattern provides distributed transactions without 2PC by composing local ACID transactions with compensating transactions for rollback.
| Property | ACID | BASE | Practical Example |
|---|---|---|---|
| Consistency Model | Strong (linearizable or serializable) | Eventual (replicas converge over time) | Bank balance vs. Twitter likes count |
| Availability | May reject requests to preserve consistency | Always responds (may return stale data) | PostgreSQL vs. Cassandra during partition |
| Performance | Lower throughput due to locking and coordination | Higher throughput; no distributed locking | MySQL TPS vs. Cassandra TPS at scale |
| Failure Handling | Rollback to last consistent state | Compensate forward; resolve conflicts | 2PC rollback vs. Saga compensating tx |
| Scalability | Vertical primary; horizontal via read replicas | Linear horizontal scaling | PostgreSQL vs. DynamoDB at 1M TPS |
| Use Case | Financial transactions, inventory, reservations | User sessions, social feeds, IoT telemetry | Payment ledger vs. activity stream |
| Representative DBs | PostgreSQL, MySQL, Oracle, SQL Server | Cassandra, DynamoDB, CouchDB, Riak | Core banking vs. recommendation engine |
Real-World Example
Airbnb uses both: PostgreSQL (ACID) for financial transactions and booking state where double-booking would be catastrophic, and Cassandra (BASE/AP) for messaging, activity feeds, and analytics — a common hybrid pattern where the choice of consistency model is driven by the cost of inconsistency in each specific domain.