Supabase disaster recovery tiers: daily backups, PITR, warm standby - RPO, RTO, and cost

A disaster recovery (DR) policy is written in recovery point objective (RPO - how much data you can lose) and recovery time objective (RTO - how long you are down), and Supabase gives you three tiers with very different numbers on both. The incident mechanics and the standby build are the companion docs - the incident reference and the resilience runbook. This page is the money-and-recovery-point axis those two deliberately skip.

Provenance - the measured numbers on this page come from the edge-resilience lab experiment: logical replication from a managed primary (ap-southeast-2) to a managed standby (ap-southeast-1): W05 (replication lag) and W06 (dump and restore) on 2026-08-15, W21 (spend cap) on 2026-08-17, with the Storage numbers from W10 (2026-08-15) and W26 (2026-08-17) and the resize windows from compute-disk D09 (2026-08-19) and platform-downtime D03 (2026-08-04); the standby build and cutover rehearsal are in the runbook. The remaining figures are quoted from the cited Supabase docs and the SLA page, and the evidence table at the end of the doc splits measured from documented.

TL;DR - Daily backups are already on (Pro: 7 days, Team: 14, Enterprise: 30) with up to a day of RPO.¹ PITR is the add-on that pulls worst-case RPO to ~2 minutes for ~$100-$400/month plus a Small compute floor, and it replaces (not complements) the daily backups.¹ A hand-rolled warm standby beats both on RPO (34ms-1s, measured) and RTO (minutes, rehearsed) at the cost of a second project and owning the cutover. Your own billing state is the fourth availability class: under the Fair Use Policy the whole org can answer 402.²

The tiers on one axis

Tier	Worst-case RPO	Expected RTO	Monthly cost	Plan floor
Daily backups	up to ~24h	size-dependent restore downtime, project offline	included	Pro (7d) / Team (14d) / Ent (30d)
PITR add-on	~2 minutes	size-dependent restore downtime, project offline	~$100 (7d) / ~$200 (14d) / ~$400 (28d) + Small compute	Pro + Small compute
Warm standby (hand-rolled)	34ms-1s replication lag (measured)	minutes - a rehearsed cutover, plus a resize window (61-105 s settle across four resizes, up to 17.0 s REST outage on the Small -> Large step, compute-disk D09) if the standby runs smaller than the primary	second project’s compute at the size you will cut over to (~$10 if that is Micro) + your runbook	any paid plan
Read replicas	near-zero lag	no failover - GET-only, never promoted	same compute size as the primary, outside the $10 credits	paid plans

RPO and RTO are different axes and the table keeps them separate on purpose: PITR’s “~2 minutes” is a recovery POINT - how much data you can lose - while its recovery TIME is the size-dependent restore downtime during which the project is inaccessible.¹ The standby flips that: its RPO is the replication lag and its RTO is your cutover procedure, which is why the two are complements, not competitors - PITR for “we deleted the wrong rows yesterday”, standby for “the region is down now”.

The platform’s own framing agrees: the production checklist positions read replicas as the availability answer to a disk failure event and PITR as the durability answer to the same event.³ Replicas serve reads from another node but are never promoted and Auth always goes to the primary - they absorb read load, not outages.

Tier 1: Daily backups (already running)

On Pro, Team and Enterprise your project is backed up daily already: 7, 14 and 30 days of retention respectively.¹ Free-tier projects get nothing - the documented self-serve path is a scheduled supabase db dump (or pg_dump), kept off-site.¹ Size the schedule off the measured floor: 12.4s to dump and 6.4s to restore 10k rows through the pooler session host (edge-resilience W06, 2026-08-15); the command and the host shape are in the runbook, Part 5.

Caveats that matter when you reach for one:

Storage objects are not in database backups. The backup holds the metadata; restoring an old backup does not bring back objects deleted after it.¹ Combined with the replication finding (objects do not follow their metadata either), Storage durability is its own problem - sync objects separately, and cost it: a standby answered 400 with NoSuchBucket in the body for an object that existed on the primary, and the download-then-upload sync of a small object took under a second (edge-resilience W10, 2026-08-15); dual-writing at the client lands 200/200 with 107ms skew but a partial failure (primary 200 / standby 400) leaves the object on one side only, closed by a sync-after in 97ms (W26, 2026-08-17).
Custom role passwords are not stored. Restore from a daily backup and you reset custom-role passwords afterwards.¹
Restore is offline and size-dependent. The project is inaccessible during the restore and the downtime grows with the database. Mid-incident, restoring to a NEW project keeps the original up - the dashboard and the clone-project flow both offer it.¹

Tier 2: PITR (the add-on)

Point-in-Time Recovery archives WAL with WAL-G on top of daily physical snapshots: WAL files ship every two minutes by default (immediately past a size threshold, never when idle), so the worst-case recovery point is two minutes back.¹

The details that decide whether it fits:

Cost: ~$100, ~$200 or ~$400 per month for 7, 14 or 28 days of recovery retention, billed hourly - and explicitly NOT covered by the spend cap, because it is an opted-in add-on.¹⁴
Floor: the project must run at least Small compute.¹
Enabling PITR stops the daily backups - finer granularity makes both unnecessary. Disabling PITR later leaves physical backups only, which restore but cannot be downloaded.¹
Replication topologies must be unwound first. If the project uses subscriptions or replication slots, drop them before the restore and recreate them after; only the Realtime slot is exempted and handled automatically.¹ A project acting as your standby’s publication source loses its slots in a restore - the standby’s subscription dies with it and must be recreated (with a re-sync). Inventory them first with select * from pg_replication_slots: max_replication_slots is 10 on Micro and on Small (compute-disk D01), and a dropped subscription can leave its slot on the publisher either way - after a plain drop (edge-resilience W05) and after slot_name = none then drop (W14) - so list pg_replication_slots on the publisher and pg_drop_replication_slot any orphan first; a forgotten slot is disk growth you did not schedule.

Tier 3: the hand-rolled warm standby

The measured tier: logical replication managed-to-managed, 34ms-1057ms lag cross-region, cutover rehearsed in minutes, sessions portable via third-party-auth registration. The build and every caveat are in the runbook - what belongs here is the cost shape:

A second project at the compute you will cut over to. Micro is ~$10/month; the $10 monthly compute credits cover ONE project, so the second one is real money.⁵ Pricing the standby at Micro and resizing at cutover moves the resize window into your RTO: 61-105 s to settle across four resizes, the Small -> Large step settling in 61 s with 17.0 s of contiguous REST outage (compute-disk D09, 2026-08-19), or 131 s on Auth and 207 s on the pooler for Micro -> Small on another rig (platform-downtime D03, 2026-08-04). The full sizing table plus resize windows and quota behaviour are in the compute and disk reference.
Read replicas are not the cheap version of this. A replica runs at the primary’s compute size, its compute is not covered by the credits, and it is never promotable.⁶ It is a read-scaling feature that happens to survive a disk failure, not a DR tier.
The runbook is the cost. The standby only beats PITR on RTO if the cutover is rehearsed - sequence resync, config re-apply, routing flip - and rehearsal is your time every month.

Class zero: your own billing state

Some org-wide outages are not the platform at all. Under the Fair Use Policy, service restrictions apply when an organization continually exceeds the Free quota, exceeds the Pro quota with the spend cap on, or has overdue invoices:²

projects paused, databases switched to read-only, new launches blocked
every API request answered 402 with a restriction description in the body
applied to ALL projects in the org; dashboard data access is retained

There is a notification and grace period first (except suspected abuse). Removal: fix the cause (pay, update the card, disable the cap, or reduce usage); usage-limit restrictions also lift when the quota refills at the next billing cycle, and immediately on upgrading or disabling the spend cap.² Detection is one row in a probe table: 402 means billing, not the platform. This is also the completion of the storage billing story - cap on means eventual restriction, cap off means an uncapped bill, and that trade-off is the decision.⁴

One measured correction to a natural assumption: the spend cap is not a request-path circuit breaker. Tripping the Pro transform quota by 5 past 100 returned 200 on every render - no synchronous disallow at the boundary (measured, edge-resilience W21, 2026-08-17). The documented “further usage disallowed” rides the billing path - notification, grace period, then the restrictions above - so the first signal you can detect is still the notification, not an API error at quota+1.

What the SLA does and does not cover

Two boundaries, both from the SLA page itself.⁷

The uptime SLA is Enterprise-only. 99.9% per product per calendar month, measured per-project, per-region or globally depending on the product, and only for generally-available features - Beta and Alpha are outside it.⁷⁸ The remedy is service credits: 10%, 15%, 20% or 30% of the affected service’s monthly fees by availability band, capped at 20% of the trailing twelve months’ fees, and the credits are the sole remedy. Below Enterprise there is no uptime SLA at all - which is most of why the hand-rolled tier exists.

Support SLAs exist for Team and Enterprise. Urgent response is 24 hours 24/7x365 on Team and 1 hour 24/7x365 on Enterprise Standard and Priority Plus; business-hours limits start at High (Team: 1 business day for High and Normal, 2 business days for Low).⁷ Pro gets support access with no SLA. And on Team or Enterprise, the documented pre-launch channel is a support ticket with at least 2 weeks’ notice before a launch or heavy load event.

When you build availability on top of a non-GA feature, you are outside the contract by construction - which is another argument for the hand-rolled tier being built from GA primitives (logical replication, the Management API) rather than platform HA features.

Which do I pick

Your requirement	Tier	Why
”Oops, we dropped the wrong table this morning”	PITR	seconds-granularity point before the mistake
Compliance says “we have backups”	Daily backups	already on; just prove the restore
Free tier, any durability at all	scheduled `db dump` off-site	the only option that exists
Region down, RTO in minutes	Warm standby	the only tier that is up somewhere else
Read load, plus disk-failure cover	Read replicas	availability for reads; never a failover
Zero budget, best possible	cron `pg_dump` + object sync	measured floor: 12.4s dump / 6.4s restore at 10k rows

What to do about it

The sizing rules that follow from this page’s own numbers. Each row names the module it rests on; a row that is a design choice says so. Module ids resolve in the edge-resilience RUNLOG and the compute-disk RUNLOG.

Practice	Rests on
Run the standby at the compute size you will cut over to, and price that, not Micro: a resize at cutover costs 61-105 s to settle across four resizes, the Small -> Large step settling in 61 s with 17.0 s of contiguous REST outage, or 131 s Auth / 207 s pooler on the other rig.	compute-disk D09; platform-downtime D03
If you do run the standby small, add the resize window to the standby RTO and space two resize PATCHes by at least 2 minutes (`429 We are still processing addon changes`).	compute-disk D09
Add a Storage sync step to every tier and cost it: objects do not follow metadata (the standby answers `400`/`NoSuchBucket`; a small object’s first sync took under a second), and dual-write is not atomic (200/400 split; sync-after 97ms).	W10, W26
Before enabling PITR on a publication source, inventory subscriptions and slots with `pg_replication_slots` and drop orphans: 10 slots on Micro and Small, and a dropped subscription left its publisher slot pinning WAL in both drills (W05 plain drop; W14 after `slot_name = none`).	compute-disk D01; W05, W14
Time a restore on a copy before you need the number: this page says “size-dependent restore downtime” because no module timed one. Restore to a new project, time it, and write that down as the RTO.	design choice; not measured
Verify the 2-minute PITR recovery point with a canary insert against the WAL archive lag before quoting it into a contract; the figure here is documented, not measured.	design choice; the docs¹
Alert on the spend-cap notification and the usage page rather than on a request error: 105 renders against a quota of 100 all returned 200, so the notification is the first detectable signal.	W21, 2026-08-17
Free tier: schedule the `db dump`, ship it off the project, and size the job off 12.4s dump / 6.4s restore per 10k rows through the pooler session host.	W06, 2026-08-15

Not measured, so stated as such above: any PITR restore time or the 2-minute worst-case recovery point (the lab never enabled PITR); daily backup restore downtime at any size; tooManyConnections on a restore (recorded in the lab’s summary file with no module, date or artifact, so anecdotal); read replica behaviour through a disk failure; the full 402 restriction path (W21 proved only the absence of a request-path breaker); the cutover RTO end to end (per-step timings exist: W05, W16, W17); the monthly rehearsal cadence.

Evidence

Number in this doc	Status	How it was checked
34ms-1s replication lag (34ms-1057ms cross-region)	measured elsewhere	edge-resilience lab W05, 2026-08-15: managed-to-managed logical replication, primary ap-southeast-2 -> standby ap-southeast-1, three runs. Build and caveats: the runbook
Cutover RTO (minutes, rehearsed)	measured elsewhere	the runbook rehearses the cutover; lab W05 (2026-08-15) measured the lag and session portability the cutover depends on
Spend cap: no synchronous disallow at the quota boundary	measured elsewhere	lab W21, 2026-08-17: 105 renders against the Pro quota of 100, every render returned 200
12.4s dump / 6.4s restore at 10k rows	measured elsewhere	lab W06, 2026-08-15: `pg_dump` and restore through the pooler session host, exact row count verified
Retention 7/14/30 days, PITR ~2 minutes, add-on pricing, Fair Use 402 behavior, 99.9% uptime and support SLAs	documented	Supabase docs and the SLA page, cited per claim with the footnotes below

References

Supabase, “Backups,” Supabase Docs. https://supabase.com/docs/guides/platform/backups ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴
Supabase, “Billing FAQ - Fair Use Policy,” Supabase Docs. https://supabase.com/docs/guides/platform/billing-faq#fair-use-policy ↩ ↩² ↩³
Supabase, “Production checklist,” Supabase Docs. https://supabase.com/docs/guides/deployment/going-into-prod ↩
Supabase, “Cost control - Spend Cap,” Supabase Docs. https://supabase.com/docs/guides/platform/cost-control ↩ ↩²
Supabase, “Manage Compute usage,” Supabase Docs. https://supabase.com/docs/guides/platform/manage-your-usage/compute ↩
Supabase, “Manage Read Replica usage,” Supabase Docs. https://supabase.com/docs/guides/platform/manage-your-usage/read-replicas ↩
Supabase, “Service Level Agreement.” https://supabase.com/sla ↩ ↩² ↩³
Supabase, “Feature maturity,” Supabase Docs. https://supabase.com/docs/guides/getting-started/features ↩