ACID vs BASE: Consistency Models in Databases

Direct Answer

ACID describes transaction properties; it does not by itself mean that every read always sees the latest write. BASE is an informal description of systems that may stay available with temporary inconsistency and converge later. Relational and NoSQL products can offer several isolation and consistency choices, so compare the guarantee of the actual operation, especially during a network partition.

Code Example

-- Atomic transaction: both account updates commit or neither does.
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

Whether another transaction sees old or new values, and whether a replica lags, depends on its isolation and replication path. A BASE-style system is not represented by generic SQL syntax; its write and convergence rules must come from the selected database.

Common Mistakes & Pitfalls

• Calling ACID strong consistency: ACID transaction properties and distributed read consistency answer different questions.
• Assuming eventual consistency is bounded: convergence has no universal millisecond range or maximum delay unless the system explicitly supplies one.
• Mapping SQL to ACID and NoSQL to BASE: modern products expose mixed and tunable guarantees.
• Treating BASE as always available: overload, quorum loss, validation, and other failures can still reject requests.
• Ignoring the operation: state the transaction scope, isolation, replication, and partition behavior being relied upon.