ACID vs BASE Trade-offs

7 min read · Updated 2026-04-25

ACID and BASE are two paradigms describing how databases handle concurrent operations and consistency. Understanding both is essential for choosing the right database — and for designing operations within whichever database you’ve picked.

ACID: The Classic Guarantees

ACID describes what relational databases (and now many NewSQL systems) promise for transactions.

Atomicity
A transaction is all-or-nothing. Either every operation in it succeeds, or none of them are applied.
Consistency
A transaction transitions the database from one valid state to another. Constraints (FKs, CHECKs) must hold before and after.
Isolation
Concurrent transactions don't interfere with each other. Different isolation levels offer different guarantees (next lesson).
Durability
Once committed, the change persists — even through power loss, crashes, hardware failures.

The cost of ACID

Strong guarantees come at a price:

For some workloads, this is a fair price. For others, it’s the wrong trade-off.

BASE: The Distributed-System Alternative

BASE emerged as the alternative for systems that prioritize availability and scale over strict transactional integrity.

Basically Available
The system remains available — possibly with reduced functionality — even during failures.
Soft state
State may change over time without explicit input, due to eventual consistency mechanisms.
Eventual consistency
Without further updates, all replicas eventually converge. No strict timing guarantee.

BASE accepts temporary inconsistency in exchange for availability and horizontal scalability. It’s the natural model for distributed systems where strict ACID would require painful coordination.

ACID vs. BASE Side by Side

ACID
Strong consistency, harder scaling
Right for: financial transactions, ledgers, inventory, anywhere correctness matters more than uptime. Postgres, MySQL, Spanner, CockroachDB.
BASE
High availability, eventual consistency
Right for: social feeds, recommendations, analytics, IoT ingestion, anywhere recent staleness is fine. Cassandra, DynamoDB, MongoDB, S3.

When the Choice Matters

The key question is what business invariants must hold.

Hard invariants → ACID
Account balances must never go negative. Order quantities must match inventory. Bills must equal usage. Use ACID systems with serializable transactions.
Soft invariants → BASE
Following count is approximately right. Like count is eventually right. Recommendation scores are eventually consistent. BASE systems handle this fine.

Modern Systems Blend Both

Real production systems don’t pick one paradigm. They use ACID where it matters and BASE where it doesn’t, often in the same product.

Patterns for blending

Tunable consistency
Cassandra, DynamoDB, Mongo: per-query consistency levels. ONE for fast reads, QUORUM for stronger reads, ALL for the strongest.
Async writes
Write to ACID DB synchronously; replicate to caches and search indexes asynchronously. Reads from caches accept eventual consistency.
Read-your-own-writes
After a write, route reads to the primary for a few seconds (cookie-driven). User sees their own changes immediately even if BASE underneath.
CRDT for shared state
Conflict-free replicated data types for collaborative features. Math-backed convergence without coordination.

Sagas: ACID-like Workflows in BASE Systems

When a business operation spans multiple services (each with its own database), you can’t use a single ACID transaction. The saga pattern chains local transactions with compensating actions.

1. Reserve inventory (ACID inside Inventory Service)
2. Charge payment (ACID inside Payment Service)
3. Schedule delivery (ACID inside Shipping Service)

Failure at step 3?
→ Compensate step 2: refund payment
→ Compensate step 1: release inventory

The result: business consistency through a sequence of local ACID transactions plus compensations, instead of one impossible distributed transaction. We covered this in EDA, CQRS & Sagas.

Recap