ACID

Atomicity, Consistency, Isolation, Durability

Pronunciation: AS-id

Updated September 30, 20262 min read

In short

ACID is a set of four guarantees, atomicity, consistency, isolation, and durability, that keep database transactions reliable even when errors or crashes occur.

What is ACID?

ACID is an acronym for the four properties a database transaction should have: atomicity, consistency, isolation, and durability. A transaction is a group of reads and writes that the database treats as a single unit of work. Together, the four properties promise that your data stays correct even if two users change it at once, a query fails halfway, or the server loses power.

Atomicity means all-or-nothing: either every statement in the transaction takes effect, or none do, and a failure triggers a rollback that undoes any partial changes. Consistency means a transaction moves the database from one valid state to another, never breaking rules such as primary keys, foreign keys, or CHECK constraints. Isolation means concurrent transactions don't see each other's unfinished work, and durability means that once a transaction is committed, its changes survive crashes because they have been written to permanent storage, usually through a write-ahead log.

A bank transfer is the classic analogy. Moving $100 from Alice to Bob takes two updates, a debit and a credit, and ACID ensures money never vanishes or appears out of nowhere if something fails between them. Relational databases such as PostgreSQL, MySQL, and SQLite are ACID compliant, and many NoSQL databases now offer ACID transactions too, sometimes with limits.

ACID is often contrasted with BASE (basically available, soft state, eventually consistent), a looser model used by some distributed databases that favor availability and speed. Also note that the C in ACID is not the C in the CAP theorem: in ACID, consistency means data obeys the database's rules, while in CAP it means every node returns the latest write. Finally, isolation is a spectrum rather than an absolute, and many databases default to a weaker isolation level, such as read committed, for better performance.

Key takeaways

Atomicity: a transaction either fully succeeds or is fully rolled back.
Consistency: every transaction leaves the data valid according to the database's rules.
Isolation: concurrent transactions don't interfere with each other's unfinished work.
Durability: committed changes survive crashes and power loss.
The C in ACID is not the same as the C in the CAP theorem.

Example

A bank transfer as an ACID transactionsql

-- Move $100 from account 1 to account 2 as one atomic unit
BEGIN;

UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

-- If anything above failed, run ROLLBACK instead to undo both updates
COMMIT;

Readers ask

Are NoSQL databases ACID compliant?

Some are. Many document and key-value databases now support ACID transactions, either within a single record or across several records with some limits, while others choose weaker guarantees for scale and speed. Check each database's documentation for exactly what it guarantees.

What is the difference between ACID and BASE?

ACID prioritizes correctness: every transaction is all-or-nothing and leaves the data immediately consistent. BASE, short for basically available, soft state, eventually consistent, prioritizes availability and allows copies of data to disagree briefly before they converge.

What are transaction isolation levels?

Isolation levels control how much concurrent transactions can see of each other's changes. The SQL standard defines four, from weakest to strongest: read uncommitted, read committed, repeatable read, and serializable. Stronger levels prevent more anomalies but can reduce throughput.