ACID is an acronym for the four properties a reliable transaction is expected to guarantee: Atomicity, Consistency, Isolation, and Durability. Atomicity means a transaction is all-or-nothing. Consistency means each committed transaction leaves the database in a valid state that respects its rules. Isolation means concurrent transactions do not interfere with one another, so each behaves as if it ran alone. Durability means that once a transaction commits, its effects survive crashes and power loss.
The acronym was coined by Theo Haerder and Andreas Reuter in their 1983 ACM Computing Surveys paper “Principles of Transaction-Oriented Database Recovery.” The paper builds on Jim Gray’s earlier work on the transaction concept and assembles a consistent terminological framework for describing recovery and logging schemes, packaging the guarantees a transaction must offer under the now-familiar name.
Gray’s 1981 “Transaction Concept” paper had already named atomicity, durability, and consistency as the defining properties of a transaction. Haerder and Reuter added isolation to the list and gave the set its memorable label, which is why ACID is usually credited to the 1983 survey while resting on Gray’s foundations.
ACID became the standard yardstick for what it means for a database to be trustworthy. When a system claims to be ACID-compliant, it is promising these four behaviors, and much of the engineering inside a database - write-ahead logging, locking, two-phase commit - exists to make good on that promise.