Point-in-time recovery

Point-in-time recovery (PITR) lets you rewind one project's database to a chosen second, not just to the last daily backup. If someone runs delete from invoices without a where clause at 14:32, you can restore to 14:31:59 and lose almost nothing.

PITR is included on Pro (7 days) and Business (14 days). Builder has daily backups only.

How it works

SupaHost keeps two things for your instance in a private bucket in its region: daily base backups of the Postgres server, and the stream of WAL files that records every change after them. WAL is archived at least every 60 seconds and shipped to the bucket every 20 seconds.

To restore to a point in time, SupaHost:

1. Takes the latest base backup from before your chosen time.
2. Replays WAL on top of it, in a throwaway Postgres with no network access, stopping at your chosen second.
3. Dumps just your project's database from that copy.
4. Swaps it in for the live database.

Only the project you pick is restored. Other projects on the instance keep running and aren't changed. The full process, including the short offline period, is on Restoring a project.

Restore to a point

1. Open Dashboard → your project → Backups.
2. Choose Restore to this point.
3. Pick the date and time. The picker moves in 1-second steps and uses your local time, as set on your computer.
4. Type the project name to confirm. Only the owner can do this.

The owner gets an email when the restore finishes or if it fails.

Choosing the right moment

The goal is the last second before the mistake. Some ways to pin it down:

From your own data. If the damaged table has timestamps, the last good write is a clue. Run this before restoring, while the bad state is still live:

-- Latest change that survived in a table hit by a bad UPDATE
select max(updated_at) as last_good_write
from public.invoices
where updated_at < now() - interval '5 minutes';

From cron history. If a scheduled job did the damage, its runs are timestamped:

select jobid, status, start_time, end_time
from cron.job_run_details
order by start_time desc
limit 20;

From the Activity page. Dashboard → Activity lists changes made through the dashboard and by AI agents over MCP, with times. Writes by MCP show as MCP (<token name>).

Database timestamps are usually stored in UTC, while the restore picker uses your local time. Convert before you pick. For example, 14:31:59 UTC is 15:31:59 in London during summer time.

If you aren't sure, restore a little earlier rather than later. You'd lose a few seconds of good writes rather than keep the bad one.

The newest few seconds

Because WAL reaches the bucket in batches, the most recent minute or so of writes may not be restorable yet. If you need to restore to "just now", wait a couple of minutes after the moment you want.

What PITR doesn't cover

• Storage files. PITR rewinds the database, including storage.objects rows, but not the files on disk. Files deleted after your chosen time stay deleted, and files uploaded after it stay but lose their rows. Download files regularly with Package files; see Exporting your data.
• Things stored outside the database: Edge Functions and their secrets, cron jobs, and project settings like Auth providers and custom domains.
• Times outside the window. Anything older than 7 days (Pro) or 14 days (Business) can't be restored.

If you're on Builder

Builder keeps 7 days of daily backups, and you can restore any of them, but not points in between. If losing up to a day of data would hurt, take a Back up now before risky changes, or move to Pro. See Changing plans.

Related

• Backups
• Restoring a project
• Freezing writes during a migration