What a transaction actually guarantees
Not that nothing else happens. Only that your work lands all at once or not at all — and that what you read stays still for as long as your isolation level says it does.
12 min · runs against the shop dataset
A transaction gives you two things. Atomicity: your writes land together or not at all, and a rollback costs nothing but the space the abandoned rows are still occupying. And isolation: a promise about what you are allowed to see while other transactions are working — a much weaker promise than most people assume, and the whole subject of this track.
Under MVCC, a write does not overwrite anything. It creates a new version of the row and marks the old one as deleted by your transaction. Nobody else's snapshot is disturbed, which is why readers never block writers and writers never block readers — the single most important practical property of this design, and the reason a long-running report cannot stop an update.
Every row here is a version that some snapshot can see.
| live_rowsbigint |
|---|
| 90 |
1 row · 90 examined · 1 page read
Rolling back is not undoing
A rollback does not put anything back. It marks the transaction aborted, and every row version it wrote becomes invisible by the ordinary visibility rule. The rows are still there, taking up space, until a VACUUM reclaims them — which is why a workload that rolls back constantly still bloats the table.