ACID is the set of four guarantees, atomicity, consistency, isolation and durability, that a database system gives to every transaction so that data stays correct even when many users write concurrently and the server can crash at any moment. In databases, ACID defines what it means for a transaction to be reliable: it either takes effect completely and permanently, or it leaves no trace at all.
The acronym was coined in 1983 by Theo Haerder and Andreas Reuter, building on Jim Gray’s earlier work on transaction processing. Today it is the baseline contract of relational databases such as PostgreSQL, Oracle, SQL Server and MySQL with InnoDB, and many distributed and document databases now offer it as well, although the strength of each guarantee varies by engine and configuration.
What each ACID property guarantees
Each letter of ACID addresses a different source of failure: partial execution, rule violations, interference between concurrent transactions, and loss of data after a crash. The table summarizes the guarantee, the mechanism that usually provides it and the failure it prevents in transactions.
| Property | Guarantee | Typical mechanism | Failure prevented |
|---|---|---|---|
| Atomicity | All changes apply or none do | Undo log, rollback | Half-finished updates |
| Consistency | Every commit satisfies declared rules | Constraints, triggers, application logic | Invalid states such as negative stock |
| Isolation | Concurrent transactions do not interfere | Locks, MVCC, conflict detection | Lost updates, dirty reads |
| Durability | Committed data survives crashes | Write-ahead log flushed to stable storage | Losing acknowledged commits |
The properties are not independent. Atomicity and durability are both delivered by the logging and recovery subsystem, while consistency depends on the other three: if a transaction is atomic, isolated and durable, and its own logic is correct, the database moves from one valid state to another.
How databases implement atomicity and durability
Most engines implement atomicity and durability with write-ahead logging (WAL): every change is first described in a sequential log, and the log record must reach stable storage before the commit is acknowledged. Data pages themselves can be written later, because the log contains everything needed to redo or undo them.
After a crash, recovery replays the log. Changes of committed transactions are redone if their pages never reached disk, and changes of uncommitted transactions are undone or simply ignored. The ARIES recovery algorithm, used in variations by many commercial systems, formalizes this redo-then-undo process. A commit is therefore defined by a single durable event: the commit record reaching the log.
Durability has a real performance cost, because each commit waits for a flush to disk. Engines soften it with group commit, which flushes many transactions in one write, and expose settings that trade safety for speed. The table lists common durability levels.
| Setting | Example | Data at risk on crash | Relative commit latency |
|---|---|---|---|
| Synchronous flush | PostgreSQL synchronous_commit on | None | Highest on single node |
| Asynchronous commit | PostgreSQL synchronous_commit off | A fraction of a second of commits | Lower |
| Flush about once per second | InnoDB innodb_flush_log_at_trx_commit 2 | About one second of commits after an OS crash | Lower |
| Synchronous replica | Commit waits for a standby | None, even if a server is lost | Adds network round trip |
A frequent mistake is to rely on the database setting while the storage layer lies about flushes, for example a disk with a volatile write cache and no power-loss protection. Durability is only as strong as the weakest component that acknowledges a write.
Isolation, the most negotiable ACID property
Isolation is the ACID property that databases most often relax for performance. Full isolation means serializability: the result of concurrent transactions equals some serial order of them. Because that can limit throughput, the SQL standard defines weaker isolation levels that allow specific anomalies.
| Isolation level | Dirty read | Non-repeatable read | Phantom read |
|---|---|---|---|
| Read uncommitted | Possible | Possible | Possible |
| Read committed | Prevented | Possible | Possible |
| Repeatable read | Prevented | Prevented | Possible |
| Serializable | Prevented | Prevented | Prevented |
Real engines deviate from this table. PostgreSQL, Oracle and SQL Server default to read committed, while MySQL InnoDB defaults to repeatable read. Engines based on MVCC usually provide snapshot isolation, which prevents the three classic anomalies but still allows write skew, where two transactions read overlapping data and make disjoint writes that together break a rule. PostgreSQL’s serializable level adds conflict detection to close that gap, while Oracle’s level named serializable is in fact snapshot isolation.
Stronger isolation also increases the number of aborted transactions: blocked transactions in lock-based systems can end in a deadlock, and serializable snapshot systems raise serialization failures. Applications that request strict isolation must therefore retry failed transactions automatically.
ACID compared with BASE and the CAP consistency
ACID is often contrasted with BASE, whose letters stand for basic availability, soft state and eventual consistency: the model adopted by many early NoSQL systems that favored availability and horizontal scale over immediate correctness. The difference is a design choice about guarantees, not about data format or query language.
| Aspect | ACID | BASE |
|---|---|---|
| Primary goal | Correctness of every transaction | Availability and scale |
| Visibility of writes | Immediately after commit | Eventually, after propagation |
| Conflict handling | Prevented or aborted | Resolved later or by last write |
| Typical systems | Relational databases, NewSQL | Early key-value and wide-column stores |
| Suited to | Payments, inventory, bookings | Feeds, counters, caches, telemetry |
The C in ACID is not the C in CAP. ACID consistency means that integrity rules hold after each transaction; CAP consistency means linearizability, that all replicas show the same latest value. A single-node database can be fully ACID while saying nothing about replica agreement, and distributed databases such as Spanner or CockroachDB must solve both problems at once.
Common misconceptions about ACID
- “ACID compliant” is not a single level. Two ACID databases can differ widely in default isolation and durability settings.
- Consistency is partly the application’s job. The database enforces only declared constraints; business rules expressed solely in code are protected only if every transaction implements them correctly.
- Autocommit is not a multi-statement transaction. Running two related updates as separate statements gives each one ACID guarantees, but not the pair.
- Replication does not equal durability. An asynchronous replica can lag behind, so a failover may lose commits that the primary acknowledged.
- Transactions do not span systems automatically. Writing to a database and a message queue in one step needs patterns such as the transactional outbox or two-phase commit.
Explained without jargon
ACID is a promise a database makes about every change. A group of changes either happens completely or not at all, it never breaks the rules, it is not disturbed by other people working at the same time, and once confirmed, it is never lost, even if the power goes out a second later.
Think of a bank transfer. Money must not leave one account without arriving in the other, two cashiers must not spend the same balance twice, and a printed receipt must mean the transfer is really recorded. ACID is the set of rules that makes this true inside a database.
A typical use case
A ticketing platform sells 400 seats for a concert, and at the moment sales open about 5,000 buyers try to book at once. Each booking runs one transaction: it checks that the chosen seat is free, marks it as sold, creates the order and records the payment reference. If any step fails, for example the payment reference is rejected, the whole transaction rolls back and the seat becomes available again.
The team uses SELECT ... FOR UPDATE on the seat row, so two buyers cannot both see the same seat as free, and a unique constraint on seat and event acts as a final safeguard. Commits are flushed to the write-ahead log and to a synchronous standby. When the primary server crashes during the rush, the standby takes over with every confirmed booking intact, and the event ends with exactly 400 sold seats and zero double bookings.