What is a Transaction

A transaction is a group of database operations that either all succeed or all fail as a single unit. If you transfer money from account A to account B, you need two operations: debit A and credit B. If the database crashes after debiting A but before crediting B, the money vanishes. A transaction guarantees both operations happen or neither does.

How it works

A transaction starts with BEGIN (or implicitly with the first statement). You issue reads and writes. If everything succeeds, you COMMIT — the changes become permanent and visible to other connections. If something fails, you ROLLBACK — every change since BEGIN is undone as if it never happened.

The database enforces this through the write-ahead log. Every change is written to the WAL before it is applied. On commit, the WAL records a commit marker. On crash, the database replays committed transactions and discards uncommitted ones.

Transactions also control visibility. While a transaction is in progress, other transactions may or may not see its uncommitted changes, depending on the isolation level. The strictest level (serializable) makes transactions behave as if they ran one at a time. The weakest (read uncommitted) lets you see other transactions' uncommitted writes — called dirty reads. Most databases default to read committed or repeatable read.

MVCC is the mechanism most databases use to implement isolation without excessive locking. Instead of blocking readers while a writer holds a lock, the database keeps multiple versions of each row so readers see a consistent snapshot.

Why it matters

Transactions are what make databases reliable. Without them, any crash, timeout, or error can leave your data in an inconsistent state — half a transfer completed, a counter incremented without the corresponding record. Every application that needs correct data depends on transactions.

See How Transactions Work for the full walkthrough of isolation levels and concurrency control.