How to restore a Supabase backup to a new project

Restoring to a new Supabase project is safer than overwriting the original. You can test the recovered application first and keep the source as a rollback path. The important catch is that a database restore does not recreate the whole Supabase project.

Start by checking what your backup contains. A Supabase-managed backup, a pg_dump file and an independent application backup each cover different things.

What Supabase restores to a new project

Supabase’s native Restore to a New Project feature creates a database-only copy from a physical backup or PITR point. It is available for paid projects with physical backups enabled.

The easily missed part is Storage: the database contains rows describing your objects, but not the files themselves. Supabase confirms this in its database backup documentation. A restored storage.objects row cannot recreate a missing image or upload.

Prepare the target before restoring

• Choose the recovery point and write down how much recent data you are willing to lose.
• Create or select an empty target in the required region with a compatible PostgreSQL version.
• Keep scheduled jobs, webhooks and outbound messages disabled on the target.
• Keep the source project unchanged until the target has passed its checks.
• Collect separate copies of Storage files, Function code and configuration before you need them.

Restore in dependency order

1. Database and Auth

Restore the database first. Auth users live in the auth schema, so a complete database recovery can retain accounts and password hashes. Review restore errors before moving on; a database that merely accepts connections is not proof that every schema was recovered.

2. Storage buckets and files

Recreate the bucket settings, then restore the actual object bytes to their original bucket names and paths. Compare file counts, sizes and checksums with the backup. Do not treat restored Storage metadata as evidence that the files exist.

3. Edge Functions and project settings

Deploy the Function versions that belong to the chosen recovery point. Reapply Auth, REST, Realtime and Storage settings where needed. Add secret values from your secret manager; they should not be recovered from ordinary logs or source control.

4. External services

A new project has a new URL and API keys. Update application hosting, OAuth callback URLs, webhooks, DNS, payment providers and external allowlists. Keep side effects disabled until the application tests pass.

Test the recovered application

• Sign in with a dedicated recovery account and refresh its session.
• Read and write representative records while checking row-level security.
• Download private and public files and upload one disposable test object.
• Invoke critical Edge Functions while email, payments and other side effects remain disabled.
• Compare critical record counts and business totals with the chosen recovery point.
• Check that cron jobs, queues and database extensions behave as expected.

Only cut over when these checks pass. Freeze or reconcile writes on the source, switch the application URL and keys, then enable jobs and integrations in a controlled order. Keep the old environment isolated until the rollback window closes.

Where we fit

We use an independent recovery point rather than a backup tied to the source project. To restore, you select an empty project from the connected Supabase account. We request temporary database access through OAuth, restore the database and Auth, then restore captured Storage files, Edge Functions and supported settings. A password is requested only when automatic access is unavailable.

Secret values and external systems remain manual actions. The recovery report lists them instead of reporting a complete restore. See Supabase backup and recovery for the current coverage and access model.