ACID

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.

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. 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.

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.

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. 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.

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.

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.

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.

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.

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. 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.

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.

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. 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.

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.