In SQL, what happens if you issue BEGIN while a transaction is already open?

## Transactions do not nest The SQL standard defines one active transaction per session. `START TRANSACTION` opens it; `COMMIT` or `ROLLBACK` ends it. There is no construct that opens a transaction inside a transaction and no rule for what committing an inner one would mean while the outer one is still undecided. So the question "what does a second `BEGIN` do?" has no standard answer — and the engines filled the gap differently. ## PostgreSQL: warn and ignore ```sql BEGIN; UPDATE accounts SET balance = balance - 100 WHERE id = 1; BEGIN; -- WARNING: there is already a transaction in progress UPDATE accounts SET balance = balance + 100 WHERE id = 2; ROLLBACK; -- both updates are undone: it was always one transaction ``` The second `BEGIN` does nothing except produce a warning. You still have exactly one transaction, and the eventual `COMMIT` or `ROLLBACK` covers everything. This is the benign behaviour: the worst outcome is a warning nobody reads and a mental model that is wrong but harmless here. ## MySQL: the second BEGIN commits the first transaction ```sql START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; START TRANSACTION; -- implicit COMMIT of the update above UPDATE accounts SET balance = balance + 100 WHERE id = 2; ROLLBACK; -- only the second update is undone ``` MySQL documents that beginning a transaction causes any pending transaction to be committed. The debit is now permanent, the credit is rolled back, and the accounts do not balance — with no error anywhere. This is the same failure family as DDL's implicit commit: your transaction ended without you writing an ending. ## Where this actually happens Nobody types two `BEGIN`s in a row on purpose. It happens through layering. A repository helper opens a transaction, does some work, and calls a service method that also opens a transaction because it was written to be usable standalone. On PostgreSQL the inner call quietly joins the outer transaction and the inner `COMMIT` ends the *whole* thing early — a different surprise, and often the more damaging one, since the outer caller believes it can still roll back. On MySQL the inner `BEGIN` commits the outer work outright. Either way, two layers believing they own the boundary is the bug; the engine differences only decide which shape it takes. ## The rules that avoid it 1. **One owner per unit of work.** The transaction boundary belongs to the outermost caller — a request handler, a job runner, a script. Everything below it takes part in whatever transaction it is given. 2. **Library and helper code must not open transactions.** It should either require an open one or explicitly detect that it is being called standalone. Silently opening one makes the function unusable inside a larger unit of work. 3. **Emulate nesting with savepoints when you genuinely need an inner scope.** That is the only mechanism SQL offers for undoing part of a transaction; the inner "transaction" becomes a named point, only the outermost `COMMIT` is a real commit, and frameworks that advertise nested transactions are doing exactly this underneath. 4. **Check, don't guess.** If code must be safe standalone and nested, ask the connection whether a transaction is already active rather than issuing a hopeful `BEGIN` — because what that `BEGIN` does depends on the engine. ## The interview-ready summary "Transactions don't nest in SQL. PostgreSQL warns and keeps the one you had; MySQL implicitly commits it and starts a fresh one, which can make half your work permanent. So I never let two layers own the boundary: the outermost caller opens and ends the transaction, everything below joins it, and if I need an inner scope I use a savepoint." Short, correct on both engines, and it names the design rule rather than just the trivia.