ACID and BASE are two different answers to the same underlying question: when a database cannot have perfect consistency and perfect availability at the same moment, which one gives way? ACID chooses consistency — a write either fully happens under strict guarantees or the database tells you it did not. BASE chooses availability — the system keeps responding to reads and writes even during a partition, and consistency catches up shortly after. Neither acronym is a product category; both describe a set of trade-offs a specific database, or even a specific query within that database, can lean toward.
What changed in 2026
- Tunable consistency became the norm, not the exception. DynamoDB, Cassandra, and MongoDB all let you choose consistency per read or write rather than committing to one philosophy for the whole database.
- "NewSQL" databases blurred the line further. CockroachDB, YugabyteDB, and Spanner-style systems offer ACID transactions with horizontal scale that used to be associated only with BASE systems.
- Eventual consistency got more visible tooling. Vector clocks, hybrid logical clocks, and conflict-free replicated data types (CRDTs) moved from academic papers into mainstream distributed-database documentation.
ACID in one paragraph
ACID — Atomicity, Consistency, Isolation, Durability — guarantees that every transaction leaves the database in a valid state, that concurrent transactions do not corrupt each other's view of the data, and that a committed write survives a crash. The cost is coordination: enforcing these guarantees, especially across multiple nodes, means some operations wait, retry, or get rejected rather than proceed on stale or conflicting data. Traditional relational databases — Postgres, MySQL, SQL Server — are built around this promise by default.
BASE in one paragraph
BASE — Basically Available, Soft state, Eventually consistent — inverts the priority. The system stays available and responsive even during a network partition or node failure, accepts that its internal state may be temporarily inconsistent across replicas, and guarantees only that, given enough time with no new writes, all replicas will converge on the same value. Many NoSQL databases — Cassandra, DynamoDB, and older versions of Riak — were built around this model because it scales horizontally with fewer coordination bottlenecks than strict ACID.
ACID vs BASE compared
|
ACID |
BASE |
| Priority under partition |
Consistency |
Availability |
| Read guarantee |
Always current |
May be stale briefly |
| Typical latency |
Higher (coordination cost) |
Lower (no coordination wait) |
| Scaling pattern |
Vertical, or careful horizontal |
Horizontal by design |
| Failure behavior |
May reject a write |
Accepts the write, reconciles later |
| Good fit |
Payments, inventory, bookings |
Feeds, counters, presence, caching |
Where CAP theorem fits
CAP theorem states that a distributed system facing a network partition must choose between consistency and availability — it cannot fully guarantee both at that moment. ACID and BASE are, in practice, the two sides of that choice: ACID systems tend to sacrifice some availability to preserve consistency during a partition, while BASE systems sacrifice some consistency to preserve availability. Outside of an actual partition, this trade-off is mostly invisible; it only becomes a real decision during the failure scenario CAP theorem describes.
Choosing between them
Ask what a stale read actually costs you. If a customer briefly seeing an old like-count or a slightly outdated view count causes no harm, BASE-style eventual consistency buys you availability and scale for free. If a stale read means double-spending a coupon, overselling the last unit of inventory, or a database transaction reporting a balance that is no longer true, ACID's stronger guarantees are worth the coordination cost. Many real systems use both: an ACID relational store for the ledger, and a BASE-style store for everything read-heavy and tolerant of a few seconds of lag.
FAQ
Can a single database be both ACID and BASE?
Not for the same operation, but many databases offer both modes and let you choose per query — MongoDB's multi-document transactions are ACID; a default write with weaker read concern behaves more like BASE.
Is BASE the same as no consistency at all?
No. BASE still guarantees eventual consistency — replicas converge once writes stop arriving — it just does not guarantee that every read in the meantime sees the latest value.
Why would anyone choose BASE over ACID if ACID sounds safer?
Because ACID's coordination cost limits how far and how cheaply a system scales, and for workloads where a stale read is harmless, that cost buys nothing. A view counter does not need the same guarantees as a bank ledger.
Does choosing BASE mean giving up transactions entirely?
No — many BASE-leaning databases still offer limited transactional guarantees, typically scoped to a single partition or document, even though the system as a whole is not strictly ACID.
Where to go next