ACID vs BASE
ACID guarantees mean transactions are airtight, at the cost of speed and scale. BASE relaxes those guarantees in exchange for performance and availability. Real systems pick by use case, not by ideology.
Two philosophies of data correctness
When databases first emerged, they were all built around one promise: when I commit a transaction, the data is correct. Period. This gave us ACID. Decades later, when web-scale applications hit limits that ACID-strict databases couldn't meet, a softer philosophy emerged: BASE. They are not enemies, they are different choices for different problems.
ACID, in plain English
ACID is the guarantee profile of traditional relational databases. Postgres, MySQL, Oracle, SQL Server. Four letters, four promises.
A — Atomicity
A transaction is all-or-nothing. If you transfer $50 from Alice to Bob, both the debit and the credit happen, or neither does. There is no "Alice was debited but Bob was never credited" middle state. If anything fails, the database rolls back to the pre-transaction state.
C — Consistency (database flavor, not CAP flavor)
The database moves from one valid state to another. Constraints (foreign keys, NOT NULL, CHECK) are never violated. If you have a constraint that account balances cannot be negative, no transaction is allowed to leave a balance negative. Note: the C in ACID is about constraints. The C in CAP is about replicas. Two different Cs. Confusing.
I — Isolation
Concurrent transactions do not see each other's intermediate state. If two transactions run at the same time, the result should be the same as if they ran one after the other in some order. Isolation has levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) that trade off correctness vs throughput.
D — Durability
Once a transaction is committed, it survives crashes, power loss, anything. Usually achieved by writing to a write-ahead log (WAL) on disk before acknowledging the commit.
BASE, in plain English
BASE was coined when systems like Amazon's shopping platform realized that strict ACID across thousands of nodes was making their site unavailable too often. They softened the contract.
BA — Basically Available
The system answers most of the time, even during partial failures. It might give you a stale answer, but you get an answer.
S — Soft state
The data may change over time without input, because of replication and reconciliation happening in the background.
E — Eventually consistent
If no new updates are made, given enough time, all replicas will converge to the same value. Reads in the meantime might be stale.
BASE systems trade strict correctness for availability and scale. They scale horizontally beautifully because they do not need expensive coordination on every write.
The honest trade-off table
| Property | ACID | BASE |
|---|---|---|
| Consistency | Strong, immediate | Eventual, possibly delayed |
| Availability | Lower (will refuse on partition) | Higher (keeps serving) |
| Throughput | Lower (locks, coordination) | Higher (no global locks) |
| Scale | Vertical or sharded | Horizontal, easy |
| Reasoning | Easy (linear timeline) | Hard (concurrent versions) |
| Typical engine | Postgres, MySQL, Oracle | Cassandra, Dynamo, Couch |
How to actually choose
Forget ideology. Look at the operation, not the system. A single application uses both, deliberately.
Pick ACID when: money is involved, inventory is involved, regulatory compliance is involved, the business cost of a wrong answer is high. Bank transactions, e-commerce orders, medical records, plane bookings.
Pick BASE when: staleness is tolerable, scale is large, availability matters more than precision. Social feeds, like counts, view counts, product reviews, real-time analytics dashboards.
Hybrid in the wild
Amazon famously runs an ACID database for the order/payment write path and a BASE eventually-consistent system for product reviews and "customers who bought this also bought" recommendations. Same company, both styles, on purpose.
Many modern databases let you mix per query. Cassandra lets you use a CONSISTENCY level of QUORUM (almost ACID-like for that operation) or ONE (full BASE). Spanner offers ACID at planetary scale by using atomic clocks and Paxos, but pays in latency.
Misconception: NoSQL means BASE
Not anymore. Many modern NoSQL databases (MongoDB, DynamoDB) offer ACID-like guarantees within a document or with explicit transaction support. The line between SQL and NoSQL has blurred. Pay attention to the consistency model the database actually offers, not the marketing label.
The simplest way to remember it
ACID is what your bank wants. BASE is what your Twitter feed needs. Most real systems pick ACID for the small set of money-and-inventory operations and BASE for the rest. The skill is knowing which is which without thinking about it.