Supabase backups vs point-in-time recovery (PITR): differences and pricing
PITR is not simply a better daily backup. Daily backups give you a few fixed restore points. PITR lets you choose a much more precise moment. Both are database features, and both still leave other parts of a Supabase project to you.
Supabase backups vs PITR at a glance
| Question | Daily backups | Point-in-Time Recovery (PITR) |
|---|---|---|
| Recovery points | Fixed daily snapshots | Choose a precise point inside the retention window |
| Best for | Routine recovery and older fixed points | Bad deploys, accidental deletes and write-heavy databases |
| Potential data loss | Up to the time between daily snapshots | Usually much smaller when the incident time is known |
| Storage object bytes | Not included | Not included |
| Edge Functions and secrets | Not included | Not included |
| Independent from the project | No | No |
| Restore testing | Still required | Still required |
Use PITR when losing the changes since last night is unacceptable. Keep a separate off-platform backup when Storage files, portability, project deletion or account-level failure are in scope.
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.
PITR pricing
Supabase prices PITR by retention window, not by usage. As an add-on on Pro, Team or Enterprise:
- 7 days: $100/month
- 14 days: $200/month
- 28 days: $400/month
Enterprise can negotiate longer custom windows. PITR also requires at least a Small compute add-on, billed separately, so the number on the pricing page is not the number on the invoice.
Enabling PITR replaces daily backups for that project rather than adding to them: Supabase stops taking separate daily snapshots once continuous WAL replay is running. Free projects cannot add PITR at all, it requires a paid plan first.
A write-heavy project on the 28-day tier is looking at several hundred dollars a month before compute, storage or anything else. That is a reasonable price for second-level rollback on a live, healthy project. It is not a substitute for an independent backup: PITR only protects data still inside the same Supabase project and account, so a deleted project or a compromised account takes the recovery window down with it.
For the current tiers and compute requirements, see the Supabase PITR cost and pricing guide.
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
A fairly sensible production setup is PITR for precise rollback, logical backups for portability, and a separate copy of Storage files. That may look repetitive on a diagram, but each part solves a different problem.
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.
Supabase backup and PITR questions
Does Supabase PITR include Storage files?
No. PITR replays database state. Storage metadata is in PostgreSQL, but the actual object bytes are separate. See the Supabase Storage backup guide.
Does PITR replace daily backups?
For a project with PITR enabled, Supabase uses continuous recovery instead of continuing to create separate downloadable daily logical snapshots. Check the current platform documentation and your project plan before relying on a particular retention window.
Do you need both PITR and an independent backup?
They cover different failure boundaries. PITR is the fastest database rollback inside a healthy Supabase project. An independent recovery point can survive outside that project lifecycle and can include Storage bytes, Function artifacts and supported configuration.
Can PITR recover a deleted Supabase project?
No. Native recovery points are removed with the project. Recovery after project deletion requires a copy stored independently from the deleted project and account lifecycle.