ACID, dismantled

Which mechanism provides each letter of ACID, and which letter was never a mechanism?

In 1983 Härder and Reuter gave the acronym ACID to a list of properties that engineers already took for granted:

• Atomicity: all of the transaction's changes take effect, or none do.
• Consistency: the data obeys its rules (constraints) before and after.
• Isolation: concurrent transactions do not see each other's half-finished work.
• Durability: once the database says "committed", the data survives a crash.

The acronym bundles three mechanisms and one non-mechanism. Treating it as one unit is the reason people believe you must give up all four together.

A comes from logging. D comes from logging. They are the same log read in two directions. The log is a file where the database writes down every change. Redo information moves you forward after a crash (re-apply the changes of committed transactions). Undo information moves you backward after an abort (reverse the changes of unfinished transactions). Implementations bundle A and D because they share one structure. But the bundling is misleading. You can have atomicity without durability: an in-memory transaction that disappears when the process crashes is perfectly atomic while it runs. You can have durability without atomicity: append each write to a file and fsync each one separately; every write survives, but a group of them can be half done.

I comes from concurrency control (Why concurrency is different, Locking and Multiversion and optimistic schemes). It is the only letter with a really independent mechanism.

C is the application's job. The database enforces the constraints that you declared (primary keys, CHECK, foreign keys) and nothing else. The rule "a wallet never holds more money than the customer paid in" lives in your code. C is in the acronym mostly because the word needed a vowel.

This split has practical value because the four letters can be bought separately and have separate prices:

• Almost every "we gave up ACID" claim really means "we gave up I" (they use weak isolation levels), or "we gave up A across shards" (they have no distributed commit).
• Essentially nobody gives up D.
• In the other direction, a lakehouse table format (a table stored as files on object storage, plus a metadata log) gives you A through the manifest swap (explained below), D through the object store, I at the granularity of a snapshot of files, and C not at all. So "ACID on the data lake" is true letter by letter and misleading as a whole, because that kind of I behaves nothing like row-level isolation. The honest description is: atomic multi-file commits with snapshot isolation at file granularity. That is a valuable thing. It is not the thing the acronym suggests.

Two rules govern the log (derived with the write-ahead log), and each rule buys one letter:

They are two different rules serving two different letters over one shared structure.