Postgres transactions

A transaction wraps a block of SQL in BEGIN / COMMIT, giving you the ACID guarantees as a unit — either everything happens or nothing does. What's worth knowing beyond the basics: savepoints let you partially roll back within a transaction (SAVEPOINT sp1 then ROLLBACK TO sp1), useful when one sub-operation might fail but you don't want to abandon the whole thing; isolation level is per-transaction — most workloads run at Read Committed (Postgres default) but financial or counter logic often needs Serializable to prevent race conditions; long-running transactions are costly — they hold locks, prevent VACUUM from cleaning old row versions (MVCC bloat), and can cause replication lag. Keep transactions short, do the work, commit fast. The pattern of BEGIN → application code does HTTP calls → COMMIT is a bug in disguise.