ACID: Atomicity and Durability

Key Insight

The well-known ACID acronym, coined in 1983, describes the safety guarantees of transactions. Atomicity, in this context, describes what happens when a client performs multiple writes but a fault occurs before the transaction can complete. If writes are grouped into an atomic transaction and a fault (e.g., process crash, network interruption, disk full, integrity constraint violation) prevents its commitment, the transaction is aborted, and the database must discard or undo all writes made within that transaction.

The defining feature of ACID atomicity is the ability to abort a transaction on error, with all its writes discarded. This ensures that if only part of a multi-step change completes, the database is not left in an inconsistent state. Without atomicity, applications would struggle to know which changes took effect, making safe retries difficult and risking duplicate or incorrect data. By guaranteeing an all-or-nothing outcome, atomicity greatly simplifies error recovery for applications.

Durability is the promise that once a transaction has successfully committed, any data it has written will not be forgotten, even in the event of hardware faults or database crashes. In single-node databases, durability typically means writing data to nonvolatile storage like hard drives or SSDs, often complemented by a write-ahead log for recovery. In replicated databases, it may mean the data has been successfully copied to a certain number of nodes before the transaction is acknowledged as committed. While perfect durability is not possible, a combination of techniques, including disk writes, replication to remote machines, and backups, is crucial to mitigate data loss risks. SSDs, for instance, have shown data loss within weeks if disconnected from power, and 30 to 80 percent of drives develop bad blocks within four years.