Overview
This page is the atomic definition. Distributed consistency trade-offs live at postgres.
Definition
BASE is a backronym that describes how many distributed NoSQL systems behave in contrast to acid relational databases. Basically Available: the system returns a response (possibly stale or partial) rather than refusing to serve a request during a network partition. Soft state: the system’s state may change over time even without new input, because updates propagate asynchronously across nodes. Eventually consistent: given enough time and no new updates, all replicas converge to the same value. BASE systems include DynamoDB, Cassandra, CouchDB, and many caches. PostgreSQL with read-replica lag exhibits BASE-like behavior for read-replica reads: the replica is eventually consistent with the primary. The CAP theorem formalizes the trade-off: a distributed system can guarantee at most two of Consistency, Availability, and Partition tolerance.
When it applies
Accept BASE semantics for shopping cart counts, view counters, social media feeds, and search indexes, where a few seconds of staleness is acceptable. Reject BASE for financial balances, inventory counts, and any domain where reading stale state causes incorrect decisions.
Example
A product page shows “In stock” even though the last unit sold 500 ms ago on another node. The inventory replica has not yet received the update. The user places an order; a downstream compensating transaction handles the oversell.
Related concepts
- acid - the stronger consistency model that BASE trades away.
- read-replica - a Postgres feature that introduces BASE-like eventual consistency.
- transaction-isolation - the ACID mechanism that BASE systems relax.
- materialized-view - materialized views can serve stale reads intentionally.
Citing this term
See BASE (llmbestpractices.com/glossary/base).