ACID

ACID is a set of properties that guarantee reliable processing of database transactions. Every transaction in a relational database must satisfy all four properties to maintain data integrity, even in the face of errors, power failures, or concurrent access.

Atomicity

A transaction is an indivisible unit of work — either all operations complete successfully, or none of them take effect. If any step fails, the entire transaction is rolled back to its previous state.

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;  -- Both happen, or neither happens

If the system crashes between the two UPDATEs, the WAL ensures the partial transaction is undone during recovery.

Consistency

A transaction moves the Database from one valid state to another. All integrity constraints (primary keys, foreign keys, check constraints, triggers) must hold before and after the transaction. If a transaction would violate any constraint, it is aborted.

Isolation

Concurrent transactions execute as if they were serial — one transaction’s intermediate state is invisible to others. In practice, DBMS implementations offer different isolation levels that trade strictness for performance:

Level	Dirty Reads	Non-Repeatable Reads	Phantom Reads
Read Uncommitted	Possible	Possible	Possible
Read Committed	No	Possible	Possible
Repeatable Read	No	No	Possible
Serializable	No	No	No

Isolation is enforced through locking, MVCC, or a combination of both.

Durability

Once a transaction is committed, its changes are permanent — they survive system crashes, power failures, and disk errors. This is guaranteed by flushing log records to stable storage before acknowledging the commit.

ACID vs BASE

ACID prioritizes consistency and correctness and is the default model for relational databases. BASE (Basically Available, Soft state, Eventually consistent) relaxes these guarantees in favor of availability and partition tolerance, commonly used by NoSQL Databases and distributed systems. See CAP Theorem for the underlying trade-off.