ACID vs BASE: Transaction Models Explained

What and Why

ACID and BASE are two ends of a spectrum describing how a data system handles concurrent writes, failures, and consistency. ACID (Atomicity, Consistency, Isolation, Durability) is the classic relational model. BASE (Basically Available, Soft state, Eventual consistency) is the model that popular NoSQL systems chose to scale horizontally.

Understanding both is essential because most real systems mix them: an order service might be strictly ACID while its analytics pipeline is happily BASE.

Mental Model

ACID says: a transaction either happens completely or not at all, leaves the database in a valid state, appears to run alone, and survives crashes. BASE says: the system stays available even during partitions, individual nodes may disagree temporarily, and replicas converge given enough time.

The trade-off lives in the CAP theorem: under a network partition, you can have consistency or availability, not both. ACID systems typically choose consistency; BASE systems choose availability.

Hands-on Example

Consider transferring 100 from Alice to Bob.

ACID version (Postgres):

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'alice';
UPDATE accounts SET balance = balance + 100 WHERE id = 'bob';
COMMIT;

Either both updates happen or neither. No other transaction sees a half-applied state.

BASE version (DynamoDB-style):

1. Write debit event to Alice's partition
2. Publish event to a topic
3. Consumer applies credit to Bob's partition
4. Reconciliation job catches drift

Each step is locally atomic, but a reader might see Alice debited and Bob not yet credited. The system relies on idempotency and reconciliation to converge.

ACID                         BASE
-----                        -----
BEGIN                        write debit (local)
debit alice    \               |
credit bob      > one atomic   v
COMMIT          /  unit       publish event
                               |
crash before COMMIT?             v
-> rollback, no change       apply credit
                               |
read mid-transaction?            v
-> sees old state            eventually consistent
                            reader may see drift

ACID gives you immediate correctness with one node coordinating. BASE gives you availability and horizontal scale at the cost of temporary inconsistency.

Common Pitfalls

People often equate ACID with “SQL” and BASE with “NoSQL”. This is outdated. CockroachDB, Spanner, and YugabyteDB give you ACID across regions. MongoDB and DynamoDB now support multi-document transactions. The labels describe guarantees, not products.

Another trap is assuming “eventual consistency” means “fast convergence.” It can mean seconds, minutes, or - if a consumer is down - hours. Always ask: what is the maximum staleness my product can tolerate?

A subtler pitfall is mixing the two without rigor. A common bug pattern is a microservice that does a local ACID transaction, publishes an event, and crashes between the two. Now the database and the event log disagree. The fix is the transactional outbox pattern: write the event into the same transaction as the state change, then a relay reads it and publishes asynchronously.

Finally, do not assume “Isolation” means serializable. Most databases default to weaker levels (Read Committed in Postgres, Repeatable Read in MySQL). Read the docs, then test with a concurrent workload.

Practical Tips

Default to ACID for anything involving money, inventory, identity, or anything a human will complain about being wrong. The cost is usually a single primary node, which is fine until you have very high write volume.

Choose BASE when availability is more important than strict consistency: shopping cart contents, social feeds, analytics events, caches. Design every BASE write to be idempotent so retries are safe.

When you genuinely need both - global scale and strong consistency - look at modern distributed SQL systems. They use consensus protocols like Raft or Paxos and clock-based ordering to give you serializable transactions across regions, at the cost of higher write latency.

Make consistency requirements explicit per use case. Document, for each read path, what staleness is acceptable. That single document avoids most architecture debates.

Wrap-up

ACID and BASE are not opposing camps; they are tools for different problems. ACID buys you correctness and simple reasoning. BASE buys you availability and scale. Real architectures mix them deliberately: strict transactions where business invariants live, eventual consistency where speed and uptime matter more than instant agreement. Pick consciously, write down the guarantees, and your system will behave the way users expect.