The complete guide to Supabase backup

Every paid project gets one backup per day, taken as a physical snapshot of the Postgres volume. The Free tier has no daily backups at all. If you need finer granularity than a 24-hour window, that's what Point-in-Time Recovery is for, and it's a paid add-on.

Supabase itself is SOC 2 Type II and ISO 27001 certified, but compliance of the platform does not automatically make your backup strategy compliant. Auditors ask whether you have an off-site copy of customer data, whether restores are tested, and whether the backup location respects data-residency rules. Native same-region snapshots alone usually don't satisfy those requirements, which is why teams under GDPR or SOC 2 scope add an off-site backup they control.

Retention is tied to your plan: 0 days on Free, 7 days on Pro ($25/mo), 14 days on Team ($599/mo), and 30 days on Enterprise. Once a backup ages out of that window, it's gone. If you need longer retention for audit or legal reasons, you need a separate off-site archive.

Yes for logical backups and restores. The CLI wraps `pg_dump` and `pg_restore` against your project's connection string, which produces a portable dump file you can keep anywhere. It does not expose the native physical snapshots, and it does not cover Storage objects or Edge Functions, so the CLI path is one piece of a full backup plan rather than the whole thing.

Open your project on a Pro plan or higher and confirm that daily backups are listed in the dashboard, then note your retention window. After that, the two gaps to close are Storage objects and Edge Functions code and secrets, because neither is in the native snapshot. The rest of this guide walks through how to cover each one.

No. Point-in-Time Recovery is a paid usage-based add-on on Pro and Team, billed on top of the plan price. It's usually included on Enterprise. If you want PITR on a Pro project, you enable it from the project's add-ons page and pay per-day of WAL retention.

A physical backup copies the raw database files or volume block-for-block. Supabase's native daily backup is a physical snapshot of the Postgres volume. A logical backup, produced by `pg_dump`, contains the SQL statements needed to rebuild your schema and data, which makes it portable across Postgres versions and providers but slower to produce on large databases.

Yes, with caveats. Native physical snapshots can be restored onto a new project in the same region through Supabase support or the dashboard restore flow, and a `pg_dump` file can be loaded into any fresh Supabase project using `pg_restore`. Cross-region moves and version differences add friction, so test the restore path before you need it.

Yes. The `auth` schema lives in the same Postgres database as your application tables, so it's included in both the native snapshot and any `pg_dump` that covers the full database. What is not included is any secret or OAuth configuration that lives outside Postgres, such as provider client secrets set in the dashboard.

Supabase stores native backups on AWS infrastructure with encryption at rest, in the same region as the project. In transit, connections to the database use TLS. If you take your own `pg_dump` backups off the platform, encryption of the resulting file is your responsibility.

PITR is priced as a usage-based add-on on top of the plan fee. A typical Pro project with seven days of WAL retention lands near the low-hundreds-per-month range, but the exact number depends on database size and retention window. Check the add-ons page inside your project for the current figure before committing. [verify]

With daily snapshots only, your Recovery Point Objective is up to 24 hours of potential data loss, because that's the gap between backups. With PITR enabled, RPO drops to seconds, since Postgres is replaying WAL. Recovery Time Objective depends on database size and whether you're restoring onto the same project or a new one, and Supabase does not publish a committed SLA on restore duration.