Skip to main content

BASE: The Alternative Vocabulary and Where It Fits

What This Concept Is​

BASE is a deliberately opposite acronym to ACID, coined by Eric Brewer and popularized in the mid-2000s as NoSQL stores rose:

  • Basically Available: the system answers, even if the answer is partial or stale. Availability is a first-class priority.
  • Soft state: the system's state can change over time without input, because background processes (anti-entropy, read repair) converge replicas.
  • Eventual consistency: if writes stop, all replicas eventually converge to the same value.

BASE is not a rigorous specification. It is a vibes contract that says: we traded strong guarantees for availability and scale, and we accept that reads can be stale and that some conflicts may need to be resolved later.

Why It Matters Here​

You will meet systems (DynamoDB, Cassandra, Riak, many caches, many message queues in certain configurations) whose marketing says "highly available" or "scalable" but whose real contract is BASE. If you approach them with ACID expectations, you will ship correctness bugs. Conversely, if you force BASE intuitions onto a Postgres or a Spanner, you will over-engineer around problems the database already solves.

BASE is also the honest name for what happens when you weaken any of A, I, or D across a replicated system. CAP and PACELC (concept 15) are the formal frameworks; BASE is the informal vocabulary engineers use daily.

Concrete Example​

A shopping cart stored in an eventually consistent KV store across three data centers. A user in region X adds an item at time T1. A replica in region Y receives a read at time T1 + 10ms:

  • ACID/linearizable store: the read either blocks until replication catches up or returns the new item (never the old cart without it).
  • BASE store: the read returns the pre-add cart. The system is basically available: it did answer. The state is soft: it will converge. The consistency is eventual: if no more writes happen, everyone will agree within some time window (seconds, typically).

The application must either be tolerant of this (a cart that briefly looks empty and repopulates is usually fine) or must explicitly coordinate (session stickiness, read-your-writes, or vector-clock-based conflict resolution at application level).

Common Confusion / Misconception​

"BASE systems are faster than ACID systems." Not in any general sense. They are usually more available under partitions and more scalable horizontally. Latency comparisons depend entirely on workload and hardware.

"BASE = no transactions." Many modern BASE-family systems offer limited transactional primitives: single-row atomicity, conditional writes (compare-and-set), or even full ACID within a partition (DynamoDB transactions, Cassandra lightweight transactions). BASE is about the default contract, not a ban on stronger primitives.

"Eventual consistency means inconsistent." Eventual means convergence is guaranteed absent new writes. It says nothing about staleness bounds. "Eventually" can mean milliseconds or, pathologically, forever if you keep writing faster than the system can converge. Treat eventual as a floor, not a ceiling.

How To Use It​

BASE is most useful as a diagnostic vocabulary when reading vendor docs or choosing storage:

  1. When docs say "eventually consistent," ask: under what conditions? what staleness bound? which session guarantees?
  2. When docs say "strongly consistent," ask: at what granularity (row, partition, cluster)? at what latency cost? is it linearizable or just "per-row atomic"?
  3. When an application team says "we need ACID," ask which letter they actually need. Usually it is I (isolation) they want, not D.
  4. When a team says "we can use BASE because it's just a cache," ask whether the cache ever becomes the source of truth on failure. If yes, it is not just a cache.

Check Yourself​

  1. Translate each BASE letter into a statement about observable system behavior, not marketing.
  2. Give one workload where BASE is the correct trade, and one where ACID is required despite the cost.
  3. Why is "eventual consistency" a floor rather than a bound?
  4. How does "soft state" differ from "stale cache"?

Mini Drill or Application​

For each system, say whether its default contract is closer to ACID or BASE, and name the property that tipped your answer:

  1. PostgreSQL single node with default settings
  2. Cassandra with quorum reads and quorum writes
  3. DynamoDB with eventually consistent reads
  4. Redis as a primary datastore with async replication to a replica
  5. A bank ledger built on top of PostgreSQL with synchronous streaming replication to a standby

Read This Only If Stuck​