Almost every RBDMS uses undo logs to implement rollback (they physically roll back/undo the changes). It is the traditional implementation technique for a whol

Almost every RBDMS uses undo logs to implement rollback (they physically roll back/undo the changes). It is the traditional implementation technique for a whole generation of databases -- see https://en.wikipedia.org/wiki/Algorithms_for_Recovery_and_Isolation_Exploiting_Semantics https://en.wikipedia.org/wiki/Algorithms_for_Recovery_and_Is... . AFAIK only PostresSQL and possibly also Interbase/Firebird and Rdb (though I'm not 100% sure about those) work in a different way without undo logs, preferring to leave old data in the heap, step over if as required, and eventually garbage collect it later. Ancestral POSTGRES did that because its goal was to keep all versions forever and do time travel, and VACUUM just moved them off to write-only media for archival. A subset of traditional undo-based RDBMSs can also use undo logs to implement MVCC. That's primarily because the other RDBMSs didn't choose to provide snapshot isolation: instead they made writers block readers, so readers never needed to fish old row versions out of the undo log except when actually rolling transactions back. The set of databases that can do undo-based MVCC currently includes at least Oracle, DB2 (since 9.7), MySQL (InnoDB + maybe other storage engines). Note that the original implementer of PostgreSQL's WAL (REDO) logging intended to add undo log support (possibly under the influence of the super well-known ARIES design): https://www.postgresql.org/docs/7.2/static/wal.html https://www.postgresql.org/docs/7.2/static/wal.html . Somehow it's taken another 15 years for someone to try that.