ACID
ACID is a set of guarantees a database provides around transactions. It explains what the database promises when multiple reads and writes are grouped into one unit of work.
Atomicity
Atomicity means a transaction is all-or-nothing. Either every operation inside the transaction commits, or the database rolls the whole thing back.
Example: if an order creates a payment row, decrements inventory, and writes an audit event, atomicity prevents only two of those three changes from surviving.
Consistency
Consistency means a transaction moves the database from one valid state to another valid state.
The database keeps its rules intact: foreign keys still point to existing rows, unique constraints stay unique, checks still pass, and required invariants are not broken by a committed transaction.
Isolation
Isolation controls what concurrent transactions can see from each other.
Without isolation, one transaction could read another transaction's unfinished work, make a decision from it, and then be wrong if that other transaction rolls back.
Isolation levels
Isolation is not just on/off. Databases usually expose levels with different tradeoffs:
- Read Uncommitted — a transaction may see uncommitted changes from another transaction. This allows dirty reads and is rarely what application code wants.
- Read Committed — a transaction only sees data that was committed before each statement starts. It prevents dirty reads, but the same query can return different results if repeated later in the same transaction.
- Repeatable Read — a transaction gets a stable view of rows it has already read. It prevents many surprising changes inside a transaction, but different databases define the edge cases differently.
- Serializable — the strongest common level. The database behaves as if transactions ran one at a time, even when it executes them concurrently. This prevents the most anomalies, but can increase conflicts and retries.
Common anomalies
- Dirty read — reading data written by another transaction before it commits.
- Non-repeatable read — reading the same row twice and getting different values because another transaction committed between reads.
- Phantom read — repeating a query and seeing new matching rows appear because another transaction inserted them.
The practical tradeoff: stronger isolation gives simpler reasoning, but can cost throughput or force the application to retry failed transactions.
Durability
Durability means that once the database confirms a transaction as committed, the result should survive crashes.
In practice, databases usually achieve this through a durability mechanism like a write-ahead log: record the change safely first, then apply it to the main data files.
Mental model
ACID is what makes a database more than a smart file. You pay some latency and complexity for the guarantee that important changes happen completely, consistently, and durably.
For money, orders, identity, permissions, and other business-critical state, those guarantees are usually mandatory.