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

A DR policy is written in RPO (how much data you can lose) and 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.

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	second project’s compute (~$10 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.¹

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.
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).

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 full compute. Micro is ~$10/month; the $10 monthly compute credits cover ONE project, so the second one is real money.⁵
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

One of the most common org-wide outages is 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 actual 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

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 ↩