Supabase Backups vs Point-in-Time Recovery: What Each Protects
Daily backups and Point-in-Time Recovery are often discussed as if one is simply the premium version of the other. The real difference is the recovery problem they solve. Daily backups give you discrete restore points. PITR lets you choose a much more precise moment. Neither automatically makes the copy independent of the source platform, and neither covers every Supabase service.
Start with RPO and RTO
Recovery Point Objective (RPO) is the maximum amount of recent data you can afford to lose. Recovery Time Objective (RTO) is how long recovery may take. The correct backup method follows from those two numbers, not from a feature comparison table.
If a nightly backup runs at 02:00 and a destructive migration occurs at 17:00, restoring the latest daily backup can lose up to fifteen hours of work. PITR can reduce that data-loss window by replaying the database to shortly before the migration. It does not guarantee that the application is operational within your RTO; restore duration and post-restore work still matter.
What daily backups are good at
- A simple, predictable set of recovery points.
- Longer retention for historical recovery, depending on plan and policy.
- Portable exports when paired with logical dumps and off-platform storage.
- Auditable restore tests against a fixed artifact.
Supabase explains its daily backup schedule and retention by plan in the official backups guide. Read the current plan details there rather than hard-coding assumptions into a recovery runbook.
What PITR is good at
- Recovering from accidental deletes or bad deploys with a small data-loss window.
- Selecting a moment immediately before a known incident.
- Protecting write-heavy systems where losing most of a day is unacceptable.
PITR depends on a base backup plus a continuous sequence of database changes. That makes it excellent for time precision, but it remains a database recovery mechanism. It should not be interpreted as version history for Storage objects, Edge Functions, secrets, or external systems.
The gaps both options share
Storage bytes are separate
Supabase states that database backups do not include the actual Storage API objects, only their database metadata. See the Storage backup caveat in the platform documentation. Restore the database without the object bytes and your application can contain valid file records that lead nowhere.
Platform configuration is separate
Auth provider settings, API keys, Edge Function secrets, custom domains, and some service configuration must be rebuilt or restored through a separate process. Keep configuration as code where possible, and maintain an encrypted inventory for the remainder.
Same-platform copies are not full redundancy
Supabase documents that deleting a project removes its backups along with its data and configuration. That makes an independent backup outside the project lifecycle a different control, not needless duplication.
A practical decision rule
- Choose daily backups when losing up to one backup interval is acceptable and recovery can wait for a conventional restore.
- Add PITR when the business cannot tolerate that data-loss window.
- Add independent logical backups when provider or account-level failure is in scope.
- Back up Storage objects separately whenever user or application files matter.
- Test restores regardless of the mechanism. A shorter RPO does not prove a working RTO.
Use layers, not a single checkbox
For many production teams, the robust answer is daily logical backups for portability and independent retention, PITR for precise operational rollback, and a separate Storage-object backup. Each layer covers a different failure mode. Calling them “duplicate backups” hides that distinction.
If you are designing the full process, start with our guide to backing up Supabase properly, then define how you will verify every database restore. The most important metric is not how many backup features are enabled, but which incidents you can recover from within the promised window.