Data

transaction

A transaction groups several database changes into one all-or-nothing unit: either every step succeeds together, or none of them happen at all. It's the database's way of making sure you never get stuck halfway through something that should have been one indivisible act.

The classic example is moving money. Transferring $100 means subtracting from one account AND adding to another — two steps that must travel as a pair. Wrap them in a transaction and if the second step fails (or the power dies between them), the database rewinds the first too. The money is never left half-moved, vanished from one side but not arrived at the other.

In practice you BEGIN a transaction, make your changes, then COMMIT to lock them all in — or ROLLBACK to undo the whole batch if something went wrong. Until you commit, it's as if none of it happened yet, and other users don't see your half-finished work.

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

Both updates land together at COMMIT — or neither does if anything fails first.

The all-or-nothing guarantee is the 'A' (atomicity) in ACID, the set of promises reliable relational databases make about transactions.

Also called

db transactioncommit/rollbackatomic operation