A transaction is a write buffer plus an atomicity rule.

Inside the transaction, reads see your own uncommitted writes. Outside it, nothing sees them until COMMIT. That is the whole of read-your-own-writes, and the exercise implements it as a lookup that checks the buffer before the store.

ROLLBACK is therefore not an undo. The changes were never applied anywhere anyone else could see them — the buffer is discarded, or the WAL's uncommitted records are simply never replayed. Rolling back a million-row transaction is not proportionally expensive.

Durability comes from the write-ahead log: COMMIT is an fsync of the log record, not of the data pages. That fsync is the hard floor on write latency, which is why committing 1000 rows in one transaction beats 1000 transactions, and why group commit exists at all.

What a long transaction really costs is not rollback work. It is the locks it holds and the vacuum or undo horizon it pins, so old row versions cannot be reclaimed.