Supabase Backups, Scaling & Operations 2026
Supabase operations run on daily backups, a paid PITR add-on and cross-region read replicas. Only Enterprise carries a 99.9% SLA; there is no published HA add-on.
Supabase Backups & Operations verdict
Supabase operations center on three things.
Daily backups, 7 days on Pro, 14 on Team, up to 30 on Enterprise. A paid PITR add-on costs $100 for 7 days.
Budget the PITR add-on for any database over 4 GB. Pick the plan by backup retention, 7 days on Pro, 14 on Team, 30 on Enterprise, and by whether you need the 99.9% SLA, which is Enterprise only. Add cross-region read replicas for geo-distributed reads, accepting async lag. Run schema changes through the supabase CLI migrations workflow, and use preview branches per pull request. Plan vertical compute upgrades for low-traffic windows, since they cause downtime.
- There is no published HA add-on or stated failover time, and only Enterprise carries a contractual 99.9% SLA, which Pro and Team do not.
- PITR is a paid add-on, $100 for a 7-day window, and without it recovery is limited to daily backups, 7 to 30 days by plan. Vertical compute upgrades require downtime, and there is no auto-vertical-scale.
- Read replicas are asynchronous, so reads can lag, bill at the primary tier plus 1.25x disk outside the spend cap, and backups exclude Storage objects and custom role passwords.
- Daily backup retention
- 7 / 14 / 30 days
- PITR
- Add-on ($100 / 7 days)
- Read replicas
- Cross-region, async
- HA / failover
- None published
- SLA
- 99.9% (Enterprise only)
This page covers Supabase's backups, HA and day-2 ops. Latency and pricing live on their own pages.
High availability and SLA
| Service | Observed uptime (90-day) | SLA | Notes |
|---|---|---|---|
| Database | 99.86% | Enterprise 99.9% monthly | Single-node by default; no published HA add-on or failover time |
| Connection Pooler (Supavisor) | 100.0% | Enterprise 99.9% monthly | Zero downtime observed over 90 days |
| API Gateway | 99.9% | Enterprise 99.9% monthly | REST and GraphQL endpoints |
| Realtime | 99.92% | Enterprise 99.9% monthly | WebSocket change streaming |
| Enterprise SLA credits | 10% to 30% | Enterprise only | 99-99.9%: 10%; 98-99%: 15%; 96-98%: 20%; below 96%: 30%; capped at 20% of annual fees |
Check Supabase recovery and availability fit
- Recovery time: documented failover is No published HA add-on or stated failover time; single-node by default (Enterprise 99.9% SLA), stated RTO Restore downtime proportional to database size.
- Point-in-time recovery: point-in-time recovery up to 7 days back.
- Availability: availability topology not documented.
- Backups: Daily (Pro and above; Free is manual pg_dump), retained 30 days; RPO Up to 24h on daily backups, or seconds with the PITR add-on.
Based on Supabase's documented operations capabilities. Confirm SLAs against the vendor contract.
Supabase operational configuration
Link the CLI to your project, dump a logical backup (schema, data, or roles), and apply schema changes through migrations. Daily physical backups run automatically on Pro and above; pg_dump via the CLI is the manual path on Free.
# Link the CLI to your hosted project
supabase link --project-ref <project-ref>
# Dump a logical backup (schema, then data-only)
supabase db dump -f schema.sql
supabase db dump --data-only -f data.sql
# Apply schema changes as migrations
supabase migration new add_orders_table
supabase db pushRead replicas and point-in-time recovery are configured through the Management API (or the dashboard), not the CLI. Deploy a cross-region read replica and restore to a Unix timestamp with a Bearer access token. Preview branches are created with the CLI.
# Create an isolated preview branch (CLI)
supabase branches create staging --region us-east-1
# Deploy a cross-region read replica (Management API)
curl -X POST https://api.supabase.com/v1/projects/<ref>/read-replicas/setup \
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{"read_replica_region": "us-west-1"}'
# Restore to a point in time (PITR add-on; Management API)
curl -X POST https://api.supabase.com/v1/projects/<ref>/database/backups/restore-pitr \
-H "Authorization: Bearer $SUPABASE_ACCESS_TOKEN" \
-d '{"recovery_time_target_unix": 1782561600}'Supabase backups and point-in-time recovery
| Plan | Backups | Retention | Notes |
|---|---|---|---|
| Free | Manual (pg_dump) | N/A | No automatic backups; project pauses after 7 days idle |
| Pro | Daily | 7 days | Physical backups for Postgres 15.8.1.079+, else logical |
| Team | Daily (physical) | 14 days | Restoration downtime proportional to DB size |
| Enterprise | Daily (physical) | Up to 30 days | Longest retention; physical backups |
| PITR add-on | Point-in-time | 7-day window ($100) | Recommended for databases over 4 GB; WAL-based recovery |
| Backup scope | Schema + data | Excludes objects | Excludes Storage API objects and custom role passwords |
Scaling operations: read replicas and compute
| Operation | Behavior | Notes |
|---|---|---|
| Read replica (cross-region) | Async, auto-routed | GET requests geo-routed to nearest DB; non-GET hits primary |
| Read replica billing | Same tier + 1.25x disk | Not covered by the spend cap |
| Vertical compute upgrade | Requires downtime | No auto-vertical-scale; upgrade Nano to 16XL manually |
| Replication lag | Seconds to minutes | Async; replica reads may lag under heavy write load |
| Disk resize | Increase only | Disk size can only be increased, not decreased |
| Pooled connections | 12,000 / project | Supavisor transaction mode for high concurrency |
What to verify before you commit to Supabase
- There is no published HA add-on or stated failover time, and only the Enterprise plan carries a contractual 99.9% SLA; Pro and Team rely on observed uptime (Database 99.86% over 90 days), so validate availability needs against the plan
- Point-in-time recovery is a paid add-on ($100 for a 7-day window) recommended for databases over 4 GB; without it, recovery is limited to daily backups (7 days on Pro, 14 on Team, 30 on Enterprise)
- Vertical compute upgrades require downtime and there is no auto-vertical-scale, so plan upgrades for low-traffic windows and size compute with headroom rather than expecting elastic scaling
- Read replicas are asynchronous (reads can lag seconds to minutes) and bill at the primary tier plus 1.25x disk outside the spend cap, and backups exclude Storage objects and custom role passwords, so plan those separately
Supabase Backups & Operations FAQ
What backup options does Supabase offer and how long are they retained?
Daily automatic backups run on Pro for the last 7 days, Team for 14 days and Enterprise for up to 30 days. The Free plan has no automatic backups and must export manually with pg_dump. Backups cover schema and data but exclude Storage API objects and custom role passwords. Projects on Postgres 15.8.1.079 and newer get physical backups, while older ones use logical backups. Point-in-time recovery is a separate paid add-on.
Does Supabase offer point-in-time recovery?
Yes, as a paid add-on costing $100 for a 7-day recovery window, recommended for databases over 4 GB. PITR uses WAL-based recovery to roll back to a specific moment, beyond the daily backup snapshots. Without the add-on, recovery is limited to the daily backups your plan retains, 7 days on Pro, 14 on Team, 30 on Enterprise. Restore via the dashboard or the Management API restore-pitr endpoint.
What is Supabase's high-availability and SLA model?
Supabase publishes no HA add-on with a stated failover time, and databases are single-node by default. Only the Enterprise plan carries a contractual 99.9% monthly SLA, with service credits from 10% for 99 to 99.9% availability up to 30% below 96%, capped at 20% of annual fees. Pro and Team have no SLA. Observed 90-day uptime is Database 99.86%, Connection Pooler 100%, API Gateway 99.9% and Realtime 99.92%.
How does Supabase scale reads and writes?
Reads scale horizontally through cross-region read replicas, additional databases kept in sync via asynchronous replication. GET requests auto-route to the nearest database since April 2025, and non-GET requests go to the primary. Writes scale vertically by upgrading the compute add-on, Nano to 16XL, but vertical upgrades currently require downtime, and there is no auto-vertical-scale. Read replicas bill at the primary tier plus 1.25x disk.
How do I operate Supabase from the command line and API?
Use the supabase CLI for backups and schema. Run supabase link --project-ref <ref>, supabase db dump -f schema.sql or --data-only, supabase migration new <name> and supabase db push, plus supabase branches create <name> for preview branches. Read replicas and point-in-time recovery are configured via the Management API: POST /v1/projects/{ref}/read-replicas/setup with a read_replica_region, and POST /v1/projects/{ref}/database/backups/restore-pitr with a recovery_time_target_unix, both with a Bearer access token.
What operational limits should I plan around?
Plan around four limits. There is no published HA add-on or failover time, and only Enterprise has a 99.9% SLA. PITR is a paid add-on. Vertical compute upgrades require downtime. Read replicas are asynchronous, so reads can lag, and bill at 1.25x disk outside the spend cap. Disk can only be increased, not decreased, and backups exclude Storage objects and custom role passwords, so handle those separately.
Sources & verification
| Source | What was checked | Last checked |
|---|---|---|
| Supabase Official | Official product page | July 10, 2026 |
| Supabase Company Sla | Uptime SLA | July 10, 2026 |
| Supabase Guides Backups | Backups and recovery | July 10, 2026 |
| Supabase Guides Compute And Disk | Platform Compute And Disk | July 10, 2026 |
| Supabase Guides Read Replicas | Platform Read Replicas | July 10, 2026 |
| Supabase Pricing | Pricing and plans | July 10, 2026 |
| Supabase Reference Cli | CLI | July 10, 2026 |
Every fact on this Supabase page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.
Explore Supabase
Every page on Supabase in one place, you are on operations.