Explain the lifecycle of a Point-in-Time Recovery (PITR) backup in Supabase?

PITR starts from a periodic full base backup of the database, taken automatically on a schedule. From that point forward, every change is continuously captured in the Postgres write-ahead log (WAL) and archived off the primary instance as it's generated, rather than waiting for the next scheduled snapshot.

To restore to a specific moment, Supabase takes the most recent base backup before the target time and replays the archived WAL records forward, transaction by transaction, up to the exact second requested — effectively reconstructing the database as it existed at that instant, including any writes that happened seconds before an incident but excluding whatever came after it.

This has two practical consequences worth knowing. First, the restore doesn't happen in-place on the live database; it typically provisions the recovered state as a new environment you review and cut over to, so a bad restore target doesn't destroy the current production data. Second, the retention window is finite and tied to plan tier — WAL older than that window is pruned, so PITR can only reach as far back as the retention period allows, after which only daily backups (if retained longer) can help.