# What is point-in-time recovery (PITR)? Source: https://www.plutonapps.com/resources/what-is-point-in-time-recovery Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib). **Point-in-time recovery (PITR):** Point-in-time recovery (PITR) is a way of restoring a database to its exact state at any chosen moment, such as one minute before a bad deploy, rather than only to the last scheduled backup. It replays a continuous record of changes on top of a base backup. Also known as: PITR, Continuous backup. The difference between losing a day of your customers' data and losing a few seconds of it. ## How much data can daily backups lose compared with PITR? Up to a day. If something goes wrong at 5pm, restoring last night's backup loses everything written since. Supabase's documentation says it directly: even with daily backups, you could still lose a day's worth of data. With PITR you restore to a moment, not to a day, so the loss is measured in minutes. The common causes are rarely dramatic: a [schema migration](https://www.plutonapps.com/resources/what-is-a-schema-migration) that dropped the wrong column, a bug that overwrote records, a script run against the wrong project. For all of them, the question is how far back you have to go. ## How does point-in-time recovery work? PostgreSQL writes every change to a write-ahead log (WAL) before applying it. PITR keeps a base backup plus those log files, and a restore replays the log up to the moment you choose. On Supabase the WAL files are backed up every two minutes by default, which its documentation gives as a worst-case recovery point of two minutes. ## How do RPO and RTO compare for PITR and daily backups? RPO, the recovery point objective, asks how much data you can lose: up to a day with daily backups, and up to two minutes with PITR on Supabase. RTO, the recovery time objective, asks how long you can be down, and for both it is the time a restore takes: | Term | Question it answers | Daily backups | PITR on Supabase | | --- | --- | --- | --- | | RPO (recovery point objective) | How much data can we lose? | Up to a day | Up to two minutes | | RTO (recovery time objective) | How long can we be down? | Time to restore | Time to restore | Whatever you choose, restore once on purpose before you need to. A backup nobody has restored is a hope, not a plan. ## What does point-in-time recovery need on Supabase? On Supabase, PITR is a paid add-on on every paid plan from Pro upward, and its backups documentation says a project using it must also run at least a Small compute add-on. You choose a recovery window of 7, 14 or 28 days, priced accordingly. Without it, daily backups are kept for 7 days on Pro, 14 on Team and up to 30 on Enterprise. - Restoring makes the project unavailable while it runs, and longer for larger databases. - Backups cover the database, not the files in Supabase Storage: they hold only the objects' metadata, so a restore does not bring back deleted files. - Budget for the PITR add-on and the compute add-on together, not only the PITR line. ## How do you restore a Supabase project to a point in time? First stop whatever is still writing bad data, such as a job or a deploy. Then, in the dashboard, open Database, then Backups, then Point in Time, choose Start a restore and pick the date and time just before the problem. Confirm, and check the result once the restore finishes: 1. **Stop the damage** Pause whatever is still writing bad data, such as a job or a deploy, so the moment you pick stays the right one. 2. **Pick the moment** In the dashboard, open Database, then Backups, then Point in Time, choose Start a restore and select the date and time just before the problem. 3. **Confirm and check** Confirm, wait out the downtime, then check the affected tables and tell users what was lost, if anything. Our guide to [Supabase backups and disaster recovery](https://www.plutonapps.com/resources/supabase-backups-disaster-recovery) covers the rest of the plan, and backups are one of the questions in the [production readiness check](https://www.plutonapps.com/tools/production-readiness-check). ## Frequently asked questions ### Does Supabase include point-in-time recovery? Supabase backs up paid-plan projects daily. Point-in-time recovery is an add-on on every paid plan from Pro upward, restoring to any moment down to seconds, and it requires at least a Small compute add-on. Whatever your plan, restore once on purpose before you depend on it. ### Does a Supabase backup include files in Storage? No. Supabase's documentation says database backups hold only the metadata of objects stored through the Storage API, not the files themselves. Restoring an old backup therefore does not bring back files deleted since then, so anything you cannot afford to lose in Storage needs its own copy. ### Is the app down during a point-in-time restore? Yes. Supabase's documentation says the project is inaccessible while a restore runs, and that larger databases take longer. Plan for that downtime: tell users, pause jobs that write data, and practise a restore once on purpose so you know roughly how long your own database takes. ### What is the difference between PITR and a daily backup? A daily backup is a snapshot taken once a day, so restoring it loses everything written since. PITR keeps a base backup plus a continuous log of changes and can restore to any chosen moment. On Supabase that means losing at most about two minutes rather than a day. ## Read next - [Supabase backups and disaster recovery](https://www.plutonapps.com/resources/supabase-backups-disaster-recovery) ## Sources - [PostgreSQL documentation: Continuous Archiving and Point-in-Time Recovery](https://www.postgresql.org/docs/current/continuous-archiving.html) - [Supabase documentation: Database backups](https://supabase.com/docs/guides/platform/backups)