PostgreSQL: point-in-time recovery (PITR) with WAL

Monday, 2:07 p.m., a migration script goes into production. It was supposed to regularise the weekend's payments; its last query lost its WHERE clause during review. Nobody notices. At 3:30 p.m., the bank reconciliation no longer balances: every transaction has an amount of zero. You restore the 2 a.m. dump, the service comes back, and thirteen hours of payments vanish along with the blunder. The path's first two labs dealt with the time to restore service. This one tackles the other figure, the one nobody had asked for: the amount of data lost. With one backup a day, no restore, however fast, gets below 24 hours of losses: what was not backed up no longer exists. You need to change the mechanism. You set up continuous archiving of the transaction logs to S3, then you prove it on an incident you trigger yourself: you rerun the faulty script on a live database, and bring it back to the second before. A recovery plan that has never been rehearsed is not a plan, it is a hope. The sandbox starts with production running, one transaction every two seconds, the 02:00 dump already on S3, and the WAL archiving still to be built.