ACID
The four guarantees a transactional database makes so concurrent, interrupted work never leaves data half-done.
ACID names the four guarantees a transactional database makes about a group of operations wrapped in a transaction: atomicity (all of it happens or none of it does — no partial writes survive a crash mid-transaction), consistency (a transaction only moves the database between states that satisfy its own declared constraints, like foreign keys and check constraints), isolation (concurrent transactions don't see each other's uncommitted, in-progress work), and durability (once committed, a transaction survives a crash the instant after, because it was written to a durable log before the client was told it succeeded).
Isolation is where the real subtlety lives, because "isolated" is a spectrum, not a boolean. Full serializability — transactions behave as if run one at a time in some order — is the strongest and most expensive level; most databases default to something weaker, like read committed or snapshot isolation, which permits specific anomalies (a repeated read within one transaction seeing different values, for instance) in exchange for much better concurrency. Choosing an isolation level is choosing which anomalies you can live with, not choosing whether there are any.
ACID is a single-node concept at heart — it describes what one database's transaction log can guarantee about its own state. Stretching those same guarantees across multiple databases or services is a much harder problem, which is why Two-Phase Commit and consensus protocols exist as separate, heavier machinery rather than ACID simply "scaling up." The opposite pole, BASE (Basically Available, Soft state, Eventually consistent), is the deliberate trade many distributed systems make instead — see Eventual Consistency and the CAP Theorem for why.
See also2
Related2
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from14
- Atomic File WriteSystems & Tooling
Replacing a file so that readers and crashes see either the complete old version or the complete new one, never a half-written mix, by writing a temporary file and renaming it over the original.
- Audit LogData & Content
An append-only record of who did what, to what, and when, kept to answer questions of accountability long after the fact, and built so that even its administrators can't quietly rewrite it.
- CAP TheoremData & Content
When a network splits a distributed system, it can stay consistent or stay available, but a proven theorem says not both.
- Database ConstraintData & Content
Rules declared in the schema that the database itself enforces on every write, such as uniqueness, required values, and allowed ranges, so bad data is refused at the door rather than cleaned up later.
- Database ShardingData & Content
Splitting one dataset across multiple databases by key, trading a single point of scale for cross-shard complexity.
- Idempotency KeyData & Content
A unique token a client attaches to a request so the server can recognize a retry and return the original result instead of doing the work twice, the standard defense against double charges and duplicate orders.
- Isolation LevelData & Content
How much concurrent transactions are allowed to see of each other's unfinished work, a dial between correctness and speed that most databases set lower than people assume.
- Optimistic LockingData & Content
Letting concurrent writers proceed unchecked and catching conflicts only at commit time, betting that collisions are rare.
- Page CacheSystems & Tooling
The operating system's use of spare memory to hold recently read and written file data, which makes repeated disk access fast and makes "free memory" look alarmingly low.
- Pessimistic LockingData & Content
Blocking every other writer up front for the duration of a transaction, betting that collisions are common enough to prevent rather than clean up.
- SQLiteData & Content
A complete SQL database packaged as a small library that stores everything in one file, public domain since 2000, tested to an extreme standard, and probably the most widely deployed database in the world.
- Time-of-Check to Time-of-UseSystems & Tooling
A race where a program checks a condition and then acts on it, but the world changes in between, the root of classic file-permission exploits and of double-spending bugs in web applications.
- Two-Phase CommitData & Content
A protocol for committing one transaction across multiple databases atomically, at the cost of blocking if the coordinator dies.
- Write-Behind CacheData & Content
A cache that acknowledges a write immediately and persists it to the real store later, trading durability for write latency.