ACID

Introduction

ACID is an acronym describing a set of properties that guarantee reliable processing of database transactions: Atomicity, Consistency, Isolation, and Durability. Together, these properties define the contract between a database system and its users: when a transaction commits, its effects are complete, valid, isolated from concurrent transactions, and permanent. ACID is the foundation of relational database systems from IBM's System R to modern PostgreSQL, and its guarantees have shaped the expectations of generations of application developers.

But ACID is not merely a technical specification. It is a boundary object — a concept that sits at the intersection of database theory, distributed systems, and business logic. The meaning of "consistency" in ACID is not the same as "consistency" in the CAP theorem. The "isolation" of ACID transactions is not the isolation of concurrent processes in operating systems. Understanding ACID requires holding multiple technical vocabularies simultaneously, a task that has produced decades of productive confusion.

The Four Properties

Atomicity ensures that a transaction is treated as a single unit of work: either all of its operations complete successfully, or none of them do. If a transfer of funds involves debiting one account and crediting another, atomicity guarantees that both operations occur, or that neither occurs. The mechanism is typically a write-ahead log: the database records the intended changes before applying them, allowing it to undo partial work if the transaction fails.

Consistency in the ACID sense means that a transaction brings the database from one valid state to another, preserving all declared invariants. This is a narrower meaning than consistency in distributed systems, which concerns whether all nodes see the same data. ACID consistency is about application-level validity; CAP consistency is about system-level agreement. The conflation of these two meanings has caused more engineering disasters than any other terminological ambiguity in computer science.

Isolation prevents concurrent transactions from interfering with each other. The SQL standard defines four isolation levels — Read Uncommitted, Read Committed, Repeatable Read, and Serializable — each representing a different tradeoff between correctness and performance. Serializable isolation, the strongest level, guarantees that concurrent transactions produce the same result as if they had executed sequentially. In practice, most production systems use weaker isolation for performance, accepting anomalies (lost updates, phantom reads, non-repeatable reads) that the application must handle explicitly.

Durability guarantees that committed transactions survive system failure. Once the database acknowledges a commit, the data is safe even if the power fails immediately afterward. This is typically implemented through synchronous disk writes, battery-backed caches, or replication — each of which introduces its own latency and failure modes.

ACID in Distributed Systems

The tension between ACID and distribution is one of the defining problems of modern systems engineering. ACID was designed for single-node databases, where all data resides on one machine and the transaction manager has complete visibility into the system state. In distributed databases — where data is partitioned across nodes and network latency makes synchronous coordination expensive — the ACID properties become both more necessary and more expensive to guarantee.

Eric Brewer's CAP theorem formalized this tension: in the presence of a network partition, a distributed system must choose between consistency (ACID's strong guarantees) and availability (responding to every request). This is not a proof that ACID is impossible in distributed systems; it is a proof that strong ACID in distributed systems requires accepting latency and unavailability during partitions.

Systems like Google's Spanner have attempted to resolve this tension through hardware innovation — using GPS and atomic clocks to implement TrueTime, a global clock synchronization mechanism that narrows the uncertainty window in which the CAP tradeoff becomes visible. Other systems, like Amazon's Dynamo and Apache Cassandra, abandon ACID entirely in favor of BASE semantics (Basically Available, Soft state, Eventual consistency), accepting that some applications can tolerate temporary inconsistency in exchange for availability.

The Philosophical Status of ACID

ACID is often treated as a self-evident good — the gold standard of database guarantees. But this treatment obscures a deeper question: guarantees for whom? ACID properties are defined from the perspective of the database user, not the database system. They describe what the user can assume about the state of the world after a transaction commits. They do not describe what the system must do to maintain those assumptions.

This distinction matters because it reveals ACID as a user interface contract, not a physical law. The database system can implement atomicity through logging, through shadow paging, through multiversion concurrency control, or through deterministic replay — each mechanism producing the same user-visible guarantee through different internal strategies. ACID is not a property of the implementation; it is a property of the interface.

This makes ACID a concept of genuine philosophical interest. It is a specification that is implementation-independent yet physically grounded: it abstracts away from mechanism while requiring that the mechanism produce specific observable behaviors. In this respect, ACID resembles the Church-Turing thesis: both specify what must be achieved without prescribing how to achieve it, and both derive their power from the fact that multiple independent implementations converge on the same behavior.

The persistence of ACID as a design ideal, despite decades of evidence that weaker guarantees are sufficient for most applications, reveals something about the psychology of programmers: we prefer certainty to performance, even when the certainty is purchased at the cost of systems that fail catastrophically rather than degrade gracefully. ACID is not a technical requirement; it is a comfort blanket.