ACID principles
ACID is an acronym for four properties — atomicity, consistency, isolation, and durability — that database management systems guarantee for transactions, in order to maintain data integrity even in the presence of errors, concurrent access, and system failures.
The acronym was coined by Andreas Reuter and Theo Härder in 1983 as a memorable framework for the guarantees that a reliable transaction processing system must provide. The four properties are interdependent. Isolation and atomicity work together to keep concurrent transactions from corrupting one another, while durability and consistency ensure that committed results survive failures and respect the database’s rules.
- Atomicity. A transaction is treated as a single, indivisible unit of work. Either all of its operations are applied, or none of them are. If any operation fails, the database reverts to the state it was in before the transaction began, discarding every change the transaction had made. This rollback is what makes a transaction "all-or-nothing", and it is the mechanism that prevents partial writes from leaving the database in an inconsistent state. The name borrows the same notion of indivisibility as a low-level atomic operation, lifted from a single CPU instruction to a multi-statement transaction.
- Consistency. A transaction takes the database from one valid state to another. "Valid" here is defined by the application’s invariants — schemas, constraints such as referential integrity, triggers, and business rules — rather than by replicas being in agreement. Every committed transaction must preserve these invariants, so the database never holds data that violates its own rules. This is a narrower notion of consistency than the replica consistency that concerns distributed systems, though the two are often conflated.
- Isolation. Concurrent transactions do not interfere with one another. The result of running several transactions at the same time must be the same as if they had run one after another, in some serial order. In practice full isolation is expensive, so databases offer a range of isolation levels that trade correctness for performance, each permitting certain anomalies such as dirty reads, non-repeatable reads, or phantom reads. The SQL standard defines four levels in increasing strictness. Read uncommitted permits every anomaly; read committed forbids dirty reads; repeatable read also forbids non-repeatable reads; and serializable forbids phantoms too, behaving as if transactions ran one at a time. Strict two-phase locking and other locking strategies are the common mechanisms for enforcing isolation, while concurrency control more broadly governs how interleaved operations are kept coherent. This sense of isolation is distinct from fault isolation, which is about containing failures rather than serializing access.
- Durability. Once a transaction has been committed, its effects persist even if the system crashes immediately afterwards. Durability is typically achieved by writing committed changes to non-volatile storage — and, in fault-tolerant systems, by replicating them to other nodes — before acknowledging the commit. It is one of the quality attributes of an IT system.
Trade-offs and limits
Strict ACID guarantees are easiest to provide in a single-node relational database, where a single lock manager and write-ahead log can coordinate every transaction. They become progressively harder, and more expensive, to preserve as data is replicated or sharded across nodes and transactions span more than one of them.
A distributed transaction must coordinate atomicity and isolation across independent storage systems, which typically requires protocols such as two-phase commit that block participants and add latency. Because of these costs, many distributed and NoSQL systems relax one or more ACID properties in exchange for availability and scalability. The CAP theorem frames the underlying trade-off between consistency and availability under partitions, and eventual consistency describes the weaker guarantee such systems usually adopt in place of ACID consistency. The saga pattern is a common alternative for long-running transactions that span services, abandoning distributed atomicity in favour of compensating actions.