A boundary around related operations
A business operation can modify several tables. A transfer debits one account and credits another; a transaction groups these related changes into a unit that can be committed together or canceled together.
The interface determines the actual boundary. PostgreSQL uses BEGIN and COMMIT for a transaction block and ROLLBACK to cancel uncommitted changes. Even a statement outside an explicit block executes in a transaction, and client libraries can manage boundaries automatically.
Savepoints inside a transaction
A savepoint records a position inside a transaction so that later changes can be canceled selectively. Work before it can remain while the application corrects a subsequent step.
Rolling back to a savepoint still takes place inside the enclosing transaction. Remaining changes depend on the final commit, and releasing a savepoint does not independently make them permanent. Local recovery therefore differs from completing the whole unit.
References: [1]
Isolation and scope still matter
Grouping statements does not settle every concurrency issue. Isolation rules determine which committed changes become visible, and serializable execution may reject a conflicting transaction for retry.
A local database transaction governs the state managed within that boundary. Its rollback does not by itself recall a sent message or undo an unrelated remote payment. Applications must coordinate external effects and retries separately.