Transactions and ACID in Plain Words

All or nothing

Move $30 from Ana to Ben and you must run TWO updates: subtract from Ana, add to Ben. Now imagine the server dies between them. Ana lost $30, Ben got nothing, and $30 vanished. Partial completion is worse than failure.

A transaction makes a group of statements all-or-nothing:

BEGIN;
UPDATE accounts SET balance = balance - 30 WHERE name = 'Ana';
UPDATE accounts SET balance = balance + 30 WHERE name = 'Ben';
COMMIT;

• BEGIN starts the transaction. Changes after it are provisional.
• COMMIT makes them all permanent, together.
• ROLLBACK instead throws them ALL away, as if nothing happened.

If the crash happens before COMMIT, the database recovers to the state before BEGIN. Money never half-moves.

ACID, translated

Databases promise transactions behave well under the acronym ACID:

• Atomic: all of the transaction happens, or none of it. The transfer never half-completes.
• Consistent: the rules always hold. Constraints (lesson 7-3) are never violated, even mid-crash.
• Isolated: concurrent transactions do not see each other's half-done work. Two people buying the last ticket cannot both get it.
• Durable: once COMMIT returns, the data survives a power cut. The database wrote it to disk in a recoverable way before saying yes.

This is the answer to lesson 1-2's promise: this is why thousands of simultaneous users can hammer one database and the data stays sane, and it is what a shared spreadsheet can never give you.