ACID vs BASE

ACID and BASE are two contrasting models for how databases handle data consistency and transactional guarantees. ACID -- Atomicity, Consistency, Isolation, Durability -- has been the gold standard for relational databases since Jim Gray formalized transaction processing in the 1970s. Atomicity ensures that a transaction either completes entirely or has no effect. Consistency ensures that transactions move the database from one valid state to another, maintaining all defined constraints and invariants. Isolation ensures that concurrent transactions do not interfere with each other, as if they executed serially. Durability ensures that once a transaction commits, the data survives even hardware failures.

BASE -- Basically Available, Soft state, Eventually consistent -- emerged as an alternative philosophy driven by the needs of internet-scale systems in the early 2000s. When companies like Amazon, Google, and Facebook needed to serve millions of concurrent users across globally distributed infrastructure, strict ACID guarantees became a bottleneck. Synchronous replication for consistency added unacceptable latency. Distributed transactions across shards (two-phase commit) were fragile and slow. BASE accepts that data may be temporarily inconsistent across nodes (soft state) and that the system will converge to a consistent state given enough time (eventual consistency), in exchange for higher availability and lower latency. Basically Available means the system guarantees a response to every request, even if the data is not yet consistent.

The industry narrative has evolved beyond a simple ACID-vs-BASE dichotomy. In the early NoSQL era (2008-2015), the prevailing wisdom was that you must sacrifice ACID to achieve distributed scale. Systems like Cassandra, DynamoDB, and MongoDB (in early versions) embraced BASE as a deliberate design choice. However, the NewSQL movement (starting around 2012) demonstrated that ACID guarantees could be maintained at distributed scale using consensus protocols like Raft and Paxos. CockroachDB provides serializable isolation across distributed nodes using Raft. Google Spanner provides external consistency (stronger than serializable) across global data centers using TrueTime. These systems pay a latency cost for strong guarantees but prove that ACID and distribution are not mutually exclusive.

Choosing between ACID and BASE depends on the specific consistency requirements of each data type in your system. Financial transactions, inventory management, and user account operations typically require ACID because incorrect intermediate states have real business consequences -- double-charging a credit card, overselling inventory, or losing an account update. Social media feeds, product recommendations, analytics dashboards, and session data can tolerate BASE because briefly stale data has minimal business impact and the performance benefits are substantial. Many production systems use both: an ACID relational database for core transactional data and a BASE NoSQL store for high-throughput, eventually-consistent workloads.

Consider transferring $100 from Account A to Account B. With ACID, the database guarantees that both the debit from A and the credit to B happen as one atomic unit -- if the system crashes after the debit but before the credit, the entire transaction is rolled back and no money is lost. With BASE, the debit and credit might happen at slightly different times on different nodes. For a brief moment, the $100 might appear to vanish (debited from A but not yet credited to B) or be duplicated (credited to B before being debited from A). The system will eventually converge to the correct state, but the intermediate inconsistency makes BASE unsuitable for financial operations where every cent must be accounted for at every moment.