Furthermore some rdbms use the versioning scheme instead of the checkpoint system. In that case, each row in a table has multiple historic versions of the data

Furthermore some rdbms use the versioning scheme instead of the checkpoint system. In that case, each row in a table has multiple historic versions of the data value. Each version is tagged with the transaction id. The committed transaction is still saved to the transaction log. The updates to each table in the transaction are complete, or partial in case of a crash. In that case, some tables have missing data versions tagged with the transaction id. Due redo at recovery, it's just a matter of looking at the last applied transaction in the log, checking the table rows to see if they have the transaction id tagged versions. If the version exists, skip. If not, apply the update. There's no need to go further back to reapply older transactions. The versioning system is much faster than the checkpoint system in recovery. It also has the advantage of less lock contention in multi-user operations. But it needs periodic garbage collection (vacuuming) to delete the old versions from rows and compact the tables, which can be very expensive.