Fun fact - a lot of this is kind of stuff is used in SQL databases! Before you finish a transaction (i.e. a sequence of commands), you can rollback the transact

Fun fact - a lot of this is kind of stuff is used in SQL databases! Before you finish a transaction (i.e. a sequence of commands), you can rollback the transaction. This will undo the effects of every command ran as part of the transaction. It's interesting to take a look at how different production databases implement undo: MySQL and Oracle use the "reconstructing previous states from the current state" strategy. As commands are ran, they keep track of how to undo those commands in the "undo log". If you rollback a transaction, all they do is run the commands in the undo log. Postgres uses a different strategy. When Postgres modifies a row, it marks the old row as deleted and inserts a new row. Furthermore these changes are associated with the current transaction and considered to be pending until the current transaction completes. If the current transaction fails, Postgres will use the original version of the row because the transaction that modified it never actually completed. SQL databases have a completely separate form of undo used for point in time backups. This is the ability to restore a copy of your database from any point in time in the past. As far as I know, use a combination of the "recording each state" and "reconstructing previous state from initial state". There's two parts to your typical database backup. There's the base backup which captures the state of your DB at a specific point in time. Separately there's a redo log that captures every change made to the data after the base backup was created. By replaying the changes made before a certain time, you can restore the DB to any state after the base backup was created.