Atomicity guarantees a transaction's statements all succeed or all fail together. Consistency guarantees a transaction moves the database from one valid state to another, never violating a constraint. Isolation guarantees concurrent transactions don't see each other's uncommitted changes (to a degree controlled by the isolation level). Durability guarantees a committed transaction survives a crash immediately afterward — the data is genuinely on disk, not just in memory.
Atomicity and Consistency
Atomicity is the all-or-nothing guarantee from the previous transactions topic. Consistency is broader: it means every constraint (foreign keys, CHECK, UNIQUE) is still satisfied when the transaction ends — the database enforces this by rejecting the whole transaction if any constraint would be violated, rather than leaving invalid data in place.
BEGIN;
INSERT INTO orders (customer_id, total) VALUES (999, -50.00);
-- if 999 doesn't exist (foreign key) OR total has a CHECK (total >= 0),
-- the WHOLE transaction fails — the database never lands in an invalid state
COMMIT;Isolation: what one transaction sees of another
Isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE, from weakest to strongest) control exactly how much of another in-progress transaction's uncommitted work is visible. PostgreSQL's default is READ COMMITTED: a transaction sees other transactions' changes only after they commit, never mid-flight.
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
-- the strictest level: behaves as if transactions ran one at a time,
-- at the cost of more retries/aborts under heavy concurrent load
SELECT * FROM accounts WHERE id = 1;
COMMIT;Durability: surviving a crash
Once COMMIT returns successfully, the change must be recoverable even if the power fails immediately afterward — engines achieve this with a write-ahead log (WAL), writing changes to a durable log on disk before acknowledging the commit, so a crash can replay the log to recover any committed-but-not-yet-fully-applied changes.