What's the difference between BASE and ACID?
Quick Answer
ACID (Atomicity, Consistency, Isolation, Durability) prioritizes strict correctness guarantees on every operation — the traditional relational model. BASE (**B**asically **A**vailable, **S**oft state, **E**ventual consistency) is the informal counterpart describing many distributed NoSQL systems' philosophy: prioritize staying available and responsive even under failure, accept that the system's state may be temporarily inconsistent ("soft"), trusting it converges to consistency eventually rather than immediately.
Detailed Answer
ACID — strict, transactional guarantees
Recall: Atomicity, Consistency, Isolation, Durability (see the ACID question) — a transaction is a strict, all-or-nothing unit that leaves the database in a definitively valid, immediately-consistent state once committed. This is the traditional relational database philosophy, prioritizing correctness even at some cost to availability/latency under failure or contention.
BASE — the informal AP-leaning counterpart
BASE isn't a formal specification the way ACID is a formal set of guarantees — it's a looser, descriptive term (coined specifically as a contrast to ACID) capturing the philosophy behind many distributed NoSQL systems:
- Basically Available — the system guarantees a response (availability) even during a partial failure/partition, even if that response might be based on somewhat stale data.
- Soft state — the system's state may change over time even without new input, purely due to eventual consistency mechanisms (replication catching up, conflict resolution reconciling divergent writes) — the state isn't a fixed, immediately-settled fact the instant a write happens.
- Eventual consistency — given enough time without new writes, all replicas converge to the same value (see that question).
Side-by-side
| ACID | BASE | |
|---|---|---|
| Priority | Consistency and correctness | Availability and responsiveness |
| Typical systems | Relational databases (PostgreSQL, MySQL, SQL Server) | Many distributed NoSQL systems (Cassandra, DynamoDB) |
| Consistency timing | Immediate, guaranteed at commit | Eventual, converges over time |
| CAP alignment | Leans CP | Leans AP |
Why this distinction matters practically
It's less about picking "ACID databases" vs "BASE databases" wholesale, and more about recognizing that these represent two different points on a spectrum of tradeoffs, and that some systems let you choose per-operation (e.g., DynamoDB offers both eventually-consistent reads, cheaper/faster, and strongly-consistent reads, more expensive/slower, on the same table). A candidate who can explain why a system might deliberately choose BASE-style guarantees for some data (accepting brief inconsistency for availability/scale) while insisting on ACID guarantees for other data (a financial ledger) demonstrates a more mature understanding than one who treats "ACID good, BASE bad" or vice versa as a blanket rule.