How to set RPO and RTO for Supabase
“We take daily backups” is not a recovery objective. It is a task on a schedule. The useful numbers are how much data you can lose and how long the application may stay down.
RPO: how much recent data can be lost?
Recovery Point Objective (RPO) is the maximum acceptable gap between the recovered state and the incident. If a daily backup is your only recovery point, the worst-case gap can approach one day. Point-in-Time Recovery can reduce the database gap, but its coverage must not be generalized to Storage files or external systems.
Define RPO per data class. Orders may tolerate minutes, analytics events several hours and generated thumbnails a full day. One number for the entire platform is simple but often either too expensive or too weak.
RTO: how long can recovery take?
Recovery Time Objective (RTO) is the maximum acceptable time to restore service. It includes detection, decision-making, provisioning, data transfer, database restore, Storage recovery, configuration, validation, DNS or routing changes and application warm-up.
A database that restores in twenty minutes does not prove a twenty-minute RTO. If credentials, Storage objects and Auth settings take another three hours, the application RTO is more than three hours. Measure the complete drill from incident declaration until validated user traffic.
Map objectives to Supabase recovery layers
Database recovery points
Supabase documents plan-dependent daily backup retention and optional Point-in-Time Recovery in its platform backups guide. Use daily backups for discrete recovery points and PITR when the database RPO requires finer granularity.
Independent database copy
Create a logical PostgreSQL backup outside the Supabase project lifecycle when project deletion, account compromise or platform-level loss is in scope. Portability is a different property from precise in-platform rollback; many production systems need both.
Storage recovery
Database recovery does not restore actual Supabase Storage files. Set a separate Storage RPO based on copy frequency and consistency window. Estimate RTO using real object volume and transfer throughput rather than a small test bucket.
Configuration and dependencies
Version Edge Functions and migrations. Keep an encrypted inventory of Auth settings, API keys, domains, webhooks and external-service configuration. Recovery time grows quickly when operators must rediscover these dependencies during the incident.
Work backwards from a scenario
For an accidental destructive migration, ask:
- How quickly will monitoring detect the damage?
- Can writes be stopped without losing the evidence needed to choose a recovery point?
- Is the newest clean database point precise enough for the RPO?
- Can missing writes be replayed safely from an event log or external source?
- Which Storage changes occurred after the chosen database point?
- How will the application be validated before traffic returns?
Repeat the exercise for project deletion, credential compromise, regional unavailability and silent corruption. Each scenario stresses different controls. PITR helps with a bad migration but does not by itself solve project deletion or leaked credentials.
Measure recovery instead of estimating it
- Start a timer when the drill incident is declared.
- Restore into a clean, isolated target using the production runbook.
- Validate Postgres, Auth, Storage, functions and critical user journeys.
- Record each phase, failure, manual dependency and total duration.
- Compare the observed data-loss gap and duration with the stated RPO and RTO.
- Assign fixes and repeat until the objectives are demonstrated.
What our scheduler actually guarantees
We schedule each project in its chosen timezone and give it a stable minute inside the selected hour. If the worker misses that minute, it catches up later on the same local day. A failed run becomes eligible for retry after one hour; an active dump, upload or verification prevents a duplicate scheduled run.
Those are implementation guarantees, not an RPO claim. The exact due and retry rules are public. They reduce the chance of silently missing a scheduled recovery point, but the achieved RPO still depends on cadence and the last successful backup.
A credible objective is evidence-backed
RPO and RTO should appear in customer commitments only after repeated drills demonstrate them under realistic data volume. Track restore duration as the database grows. A runbook that met the objective six months ago may fail it today.
Use the Supabase restore checklist to run the exercise, compare daily backups with PITR, and review our Supabase disaster recovery approach for independent recovery with a restore-tested database and hash-checked artifacts.