In database systems, ACID is an acronym for atomicity, consistency, isolation, and durability: four properties used to characterize reliable database transactions.[1] Together, the properties describe how a transaction behaves with respect to failure, database invariants, concurrent execution, and persistence after commit.
A common example is a transfer of money between two bank accounts. The debit and credit can be treated as one transaction: atomicity requires the transfer to take effect as a whole or not at all; consistency requires the transaction to preserve defined database invariants; isolation governs its interaction with concurrent transactions; and durability requires a successfully committed transfer to survive subsequent failures.
The acronym ACID appears in Theo Härder and Andreas Reuter's influential 1983 paper Principles of Transaction-Oriented Database Recovery, which built on earlier work on transaction processing by researchers including Jim Gray.[1]
History
The modern transaction concept developed alongside database and transaction-processing systems during the 1960s and 1970s, as systems had to coordinate concurrent operations while recovering reliably from software, hardware, and storage failures.
Jim Gray played a central role in systematizing transaction-processing concepts. His 1978 Notes on Data Base Operating Systems described concurrency control, locking, recovery, logging, checkpointing, and commit protocols.[2] In his 1981 paper The Transaction Concept: Virtues and Limitations, Gray described transactions in terms of atomicity, consistency, and durability, defining atomicity as an all-or-nothing property and durability as the survival of a committed transaction's effects after failures.[3]
Gray compared the transaction concept to a legal contract, in which work can proceed provisionally before a commitment establishes the resulting state.[3]
In 1983, Härder and Reuter published Principles of Transaction-Oriented Database Recovery in ACM Computing Surveys. The paper grouped atomicity, consistency, isolation, and durability as transaction properties and used the acronym ACID.[1] Their paper also developed a framework for comparing transaction-oriented recovery strategies.
Research subsequently refined the mechanisms used to provide these properties. IBM's System R work developed log-based transaction recovery, while C. Mohan and colleagues published ARIES in 1992, a write-ahead-log-based recovery method supporting fine-grained locking and partial rollback.[4][5] ACID subsequently became standard terminology for transactional database systems.
Properties
Atomicity
Atomicity requires a transaction to have an all-or-nothing outcome. If a transaction commits, its changes are accepted as a unit; if it aborts, its uncommitted effects do not become part of the committed database state.[3][1]
Atomicity does not mean that all of a transaction's physical operations occur simultaneously. A database may perform multiple writes at different times while using logging, versioning, shadowing, or other recovery mechanisms to ensure that a partially completed transaction does not become a partially committed result.
Consistency
Consistency requires a transaction to constitute a valid transformation of database state according to the invariants or integrity rules applicable to the database.[3][1] Such rules can include referential integrity, uniqueness requirements, type restrictions, and other integrity constraints.
Consistency differs from the other ACID properties in that the database system cannot in general determine every invariant required by an application. A DBMS can enforce declared constraints, but application logic must also ensure that transactions preserve any additional rules that are not represented directly in the database schema.
The consistency property in ACID is distinct from the consistency property in the CAP theorem. In ACID, consistency concerns preservation of database rules and invariants; in CAP, consistency refers to a consistency model for replicated data.[6]
Isolation
Isolation concerns the interaction of concurrently executing transactions. In its strongest traditional formulation, concurrent transactions behave as though they had executed serially in some order, even if their operations were actually interleaved.[1]
Database systems can provide different isolation levels, some of which permit concurrency anomalies that full serializability would prevent. Isolation can be implemented using techniques including locking, multiversion concurrency control (MVCC), optimistic concurrency control, or combinations of these approaches.
Isolation is distinct from atomicity. Atomicity determines whether a transaction's effects take place as a unit; isolation determines how concurrent transactions can interact with and observe one another.
Durability
Durability requires the effects of a successfully committed transaction to survive subsequent failures.[3][1] Database systems commonly provide durability through persistent storage together with recovery mechanisms such as transaction logs and write-ahead logging.
Relationship among the properties
The four ACID properties describe different aspects of transactional behavior and should not be treated as interchangeable.
| Property | Principal concern | Bank-transfer example |
|---|---|---|
| Atomicity | All-or-nothing outcome | The debit and credit are committed together, or neither is. |
| Consistency | Preservation of defined invariants | The transaction preserves rules governing valid accounts and balances. |
| Isolation | Interaction among concurrent transactions | Concurrent transfers do not interfere in ways prohibited by the selected isolation guarantee. |
| Durability | Persistence after commit | Once the transfer is successfully committed, its result survives subsequent failures. |
The properties can depend on related implementation mechanisms without becoming the same property. For example, transaction logging can contribute to both atomicity and durability, while concurrency-control mechanisms primarily address isolation. Consistency depends both on guarantees supplied by the DBMS and on the correctness of the transaction itself.[1]
Implementation
ACID is a description of transaction properties rather than a specification of one implementation. Database systems use different combinations of recovery, concurrency-control, storage, and commit mechanisms to provide transactional guarantees.
Recovery and logging
Atomicity and durability commonly rely on recovery mechanisms that retain enough information to reconstruct an appropriate database state after an abort or failure. These mechanisms include write-ahead logging, undo and redo records, rollback journals, shadow paging, and multiversion storage.[1]
In write-ahead logging, recovery information is made persistent before corresponding modified database pages are written to their final storage locations. PostgreSQL, for example, requires WAL records describing a change to reach persistent storage before the associated changed data pages.[7]
Other designs provide the same transaction properties differently. SQLite can use a rollback journal containing original database-page contents so that an interrupted transaction can be restored; it also provides a separate WAL mode.[8]
Concurrency control
Isolation requires a database to control interactions among concurrent transactions. One family of techniques uses locks to restrict conflicting access to data; two-phase locking can be used to obtain serializable schedules.
Another family uses multiversion concurrency control (MVCC), in which multiple versions of data allow transactions to read from an appropriate snapshot while other transactions perform updates. MVCC can reduce read–write blocking, although the guarantees obtained depend on the isolation level and concurrency-control algorithm.
The choice between locking, multiversioning, optimistic techniques, and hybrid designs is an implementation decision rather than part of the definition of ACID.
Distributed systems
ACID transactions can span multiple processes, storage engines, servers, or distributed database nodes. Providing a common transaction outcome across independent participants requires additional coordination.
Two-phase commit is a widely used atomic commit protocol for distributed transactions. Participants first prepare to commit and then receive a common commit or abort decision from a coordinator.[9] Other distributed transaction architectures use different protocols, but the goal of atomic commitment is to prevent participants from reaching incompatible transaction outcomes.
ACID, CAP, and BASE
ACID, the CAP theorem, and BASE describe different aspects of data systems and are not mutually exclusive classifications.
ACID describes properties of transactions. CAP concerns the guarantees that a distributed system can simultaneously provide when communication between nodes is disrupted by a network partition. CAP does not imply that a database must permanently choose between consistency and availability during normal operation; its restrictions apply in the presence of partitions.[6][10]
BASE (basically available, soft state, eventually consistent) was introduced as a contrasting mnemonic to ACID and is associated with distributed-system designs that may permit temporary inconsistency in order to maintain availability or reduce coordination. Brewer later described ACID and BASE as ends of a spectrum rather than mutually exclusive categories, noting that modern large-scale systems can combine aspects of both approaches.[6]
The distinction also does not map cleanly onto relational versus non-relational database models. For example, MongoDB, a document-oriented NoSQL database, introduced multi-document ACID transactions in version 4.0 in 2018 and later extended transactions to sharded clusters.[11][12] NoSQL therefore does not imply the absence of ACID transactions.
Examples in database systems
Database systems provide ACID properties using different storage and concurrency-control architectures.
| System | Examples of transactional mechanisms |
|---|---|
| PostgreSQL | Uses write-ahead logging for crash recovery and supports multiple transaction isolation levels.[7][13] |
| SQLite | Provides atomic transactions using rollback journals or WAL mode, depending on configuration.[8] |
| MySQL / InnoDB | Uses undo records for transaction rollback and consistent reads, redo logging for crash recovery, and locking and MVCC for concurrency control.[14][15] |
| MongoDB | Supports multi-document ACID transactions, including transactions across sharded clusters.[12] |
The exact strength and behavior of individual guarantees can depend on configuration, isolation level, replication settings, and failure assumptions. Consequently, describing a database as "ACID" does not by itself specify every aspect of its transactional behavior.
See also
References
- 1 2 3 4 5 6 7 8 9 Härder, Theo; Reuter, Andreas (1983). "Principles of Transaction-Oriented Database Recovery". ACM Computing Surveys. 15 (4): 287–317. doi:10.1145/289.291.
- ↑ Gray, Jim (1978). "Notes on Data Base Operating Systems". Operating Systems: An Advanced Course. Lecture Notes in Computer Science. Vol. 60. Springer. pp. 393–481. doi:10.1007/3-540-08755-9_9.
- 1 2 3 4 5 Gray, Jim (1981). "The Transaction Concept: Virtues and Limitations". Proceedings of the 7th International Conference on Very Large Data Bases. pp. 144–154.
- ↑ Gray, Jim; McJones, Paul; Blasgen, Mike; Lindsay, Bruce; Lorie, Raymond; Price, Tom; Putzolu, Franco; Traiger, Irving (1981). "The Recovery Manager of the System R Database Manager". ACM Computing Surveys. 13 (2): 223–242. doi:10.1145/356842.356847.
- ↑ Mohan, C.; Haderle, Don; Lindsay, Bruce; Pirahesh, Hamid; Schwarz, Peter (1992). "ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging". ACM Transactions on Database Systems. 17 (1): 94–162. doi:10.1145/128765.128770.
- 1 2 3 Brewer, Eric (2012). "CAP Twelve Years Later: How the "Rules" Have Changed". Computer. 45 (2): 23–29. doi:10.1109/MC.2012.37.
- 1 2 "Write-Ahead Logging (WAL)". PostgreSQL Documentation. PostgreSQL Global Development Group. Retrieved 6 September 2026.
- 1 2 "Atomic Commit In SQLite". SQLite. Retrieved 6 September 2026.
- ↑ Bernstein, Philip A.; Newcomer, Eric (2009). Principles of Transaction Processing (2nd ed.). Morgan Kaufmann. ISBN 978-1-55860-623-4.
- ↑ Abadi, Daniel J. (2012). "Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story". Computer. 45 (2): 37–42. doi:10.1109/MC.2012.33.
- ↑ "MongoDB Announces Multi-Document ACID Transactions in Release 4.0". MongoDB. 15 February 2018. Retrieved 6 September 2026.
- 1 2 "Transactions". MongoDB Manual. MongoDB. Retrieved 6 September 2026.
- ↑ "Transaction Isolation". PostgreSQL Documentation. PostgreSQL Global Development Group. Retrieved 6 September 2026.
- ↑ "Undo Logs". MySQL 8.4 Reference Manual. Oracle. Retrieved 6 September 2026.
- ↑ "Redo Log". MySQL 8.4 Reference Manual. Oracle. Retrieved 6 September 2026.
| Types | |
|---|---|
| Concepts | |
| Objects | |
| Components | |
| Functions | |
| Related topics | |
