CONCEPT Cited by 1 source

ACID properties¶

ACID is a set of four properties — Atomicity, Consistency, Isolation, Durability — that together define the guarantees a database transaction offers. Coined by Andreas Reuter and Theo Härder in their 1983 paper "Principles of Transaction-Oriented Database Recovery" (ACM Computing Surveys 15:4, DOI 10.1145/289.291), the acronym has since become the canonical framing for "what does it mean for a database to be trustworthy about a multi-statement change?"

The four properties¶

Atomicity¶

A transaction is an all-or-nothing unit of work. Either every statement in the transaction takes effect, or none of them do. A partial transaction — some statements applied, others not — is never observable by other transactions or persisted to disk. Mechanically provided by the ability to roll back (ROLLBACK) any changes made during the transaction up until COMMIT.

Canonical framing from PlanetScale's Brian Morrison II: "Atomicity means that any number of SQL operations can be executed as a single unit of work known as a transaction. … no data within the database is actually changed until the transaction is committed." (Source: sources/2026-04-21-planetscale-mysql-isolation-levels-and-how-they-work.)

MySQL has autocommit on by default, which means every statement that isn't explicitly wrapped in a START TRANSACTION / COMMIT block is implicitly its own single-statement transaction. Multi-statement atomicity requires explicit transaction demarcation.

Consistency¶

The database moves from one valid state to another, preserving invariants expressible in the schema: NOT NULL constraints, foreign keys, CHECK expressions, unique indexes, triggers with cascading effects, etc. A transaction that would violate any of these invariants is rejected before commit.

This is the narrowest of the four properties in practice — most "consistency" violations anyone worries about in production are actually isolation or durability issues, not database-level constraint failures. The C in ACID is strictly about the database's own invariants, not about application semantics.

Isolation¶

Concurrent transactions execute as if they were serial (or at a weaker level chosen by the application). The level of isolation is configurable per-transaction via isolation levels — the four-level ladder READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE trades concurrency-throughput for correctness-strength.

The key intuition: without isolation, two concurrent transactions can interleave their reads and writes in ways that make the database indistinguishable from a corrupted one — even though every individual statement succeeded. Isolation is what makes concurrent transactions compose.

Durability¶

Once a transaction commits, its effects survive failures — power loss, OS crash, hardware failure. Data written to persistent storage (HDD / SSD / NVMe) stays written. Databases that store state only in memory (like Memcached) fail the durability test.

Durability is conventionally implemented via write-ahead logging: every committed change is durably recorded in a log before the commit acknowledges success. On recovery, the log is replayed to reconstruct any writes that hadn't yet made it into the main data files.

Canonical framing: "Durability simply means that once a transaction completes, the data can survive system failures and outages by storing the data on persistent storage. Memcached, for example, stores all of its data in memory, so it would fail this requirement." (Source: sources/2026-04-21-planetscale-mysql-isolation-levels-and-how-they-work.)

Why the acronym matters¶

The four properties are orthogonal — a database can fulfil one without fulfilling another. A system offering only D (durable writes) without A (atomic composition) is a write-ahead log; useful but not a database. A system offering only I (isolation) without D (durability) is a concurrency-control library over ephemeral state.

Modern OLTP databases (MySQL / Postgres / Oracle / SQL Server) claim full ACID compliance. NoSQL databases historically traded off some properties for scale — DynamoDB, Cassandra, MongoDB started as eventually-consistent with weaker isolation, and have since added transactional modes that re-offer ACID within narrower scopes (e.g., MongoDB's multi-document transactions, DynamoDB's TransactWriteItems).

Relationship to modern distributed-systems framings¶

ACID properties as specified by Reuter & Härder assume a single database node. In a distributed setting, each property gets more complicated:

Atomicity across nodes requires a distributed commit protocol like two-phase commit or a variant like ordered commit without 2PC.
Consistency in the CAP-theorem sense is different from C in ACID — CAP-consistency means all nodes see the same data at the same time, not schema-invariant preservation.
Isolation across nodes requires a global transaction ordering mechanism (CSN / clock / GTID) and agreement on visibility order.
Durability requires replication across independent failure domains (not just disk persistence on one node).

The canonical modern distributed-systems formal framework is Adya's 2000 PhD thesis "Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions", which refines Reuter & Härder into phenomena-based formal definitions.

Seen in¶

sources/2026-04-21-planetscale-mysql-isolation-levels-and-how-they-work — Brian Morrison II's PlanetScale pedagogical post credits Reuter & Härder 1983 verbatim for coining ACID and uses it as the frame for the I-specific isolation- levels deep-dive. Each property described via MySQL- specific mechanisms: atomicity via autocommit + explicit transactions + rollback; consistency via constraints/cascades/triggers; isolation via the four-level ladder; durability via persistent-storage-vs-Memcached contrast.