Can you recover a deleted Supabase project?
Supabase cannot recover a deleted project. Deletion permanently removes the database, Auth data, Storage files, Edge Functions, project configuration and Supabase-managed backups. If an independent recovery point was stored outside that project before deletion, you can create a new project and restore what the recovery point contains. Without such a copy, the deleted data cannot be reconstructed through Supabase.
Identify the state before choosing a recovery path
| What happened | What is still available | Recovery path |
|---|---|---|
| The entire project was deleted | Nothing in the deleted Supabase project | Restore an independent copy into a new project, or accept the loss if none exists |
| A Free project was paused | The paused project or downloadable database and Storage exports | Resume it, or download the available artifacts before deletion and migrate them |
| Rows, tables or a migration damaged an existing project | The project and any eligible daily backup or PITR history | Choose a clean recovery point and restore the existing database or clone it for testing |
| Only a database dump exists after project deletion | Postgres and Auth data included in that dump | Restore the database, then rebuild missing Storage, Functions, settings and integrations separately |
Supabase states in its project deletion documentation that it cannot recover deleted projects and that project backups are removed too. Backup retention for an active project is not a grace period after deletion.
A paused project is not a deleted project
A paused Free project still has a Supabase recovery path. Depending on its age and current platform state, you may be able to resume it or download its database backup and Storage objects from the Project Overview. Do this before deleting anything. A pause preserves a route to the artifacts; deletion removes that route.
The current Supabase paused-project recovery guide restores the database into a new project, uploads Storage objects separately and then recreates project configuration. That procedure requires the paused project exports to remain available.
Recover from an independent copy in dependency order
- Create an empty Supabase target with the same or a newer PostgreSQL major version. Keep public traffic, cron jobs, webhooks and outbound messages disabled.
- Restore the database and Auth data first. Treat restore errors as fatal and compare the result with the capture-time inventory.
- Recreate Storage buckets and upload the actual file bytes at their original paths. Restored storage.objects rows alone do not contain the files.
- Deploy the Edge Function versions from the recovery point and apply supported non-secret configuration.
- Create new target API keys and restore secret values from the approved secret manager. Do not reuse credentials invalidated with the deleted project.
- Test login, row-level security, representative records, Storage downloads and critical Functions before changing application traffic.
- Update application URLs, OAuth callbacks, webhooks, DNS and external allowlists, then enable side effects in a controlled order.
The command-level database procedure and target checks are in how to restore a Supabase backup to a new project. Supabase’s native Restore to a New Project feature is useful while the source project and its physical backups still exist. It cannot read a backup from a project that has already been deleted.
What an independent recovery point must contain
Independent means the copy is not deleted by the same Supabase project-deletion action. Storage location alone is not enough: a PostgreSQL dump can recover database and Auth rows, but not Storage object bytes, deployed Edge Functions, target API keys or every project setting.
| Component | Evidence needed after deletion |
|---|---|
| Database and Auth | A logical dump plus roles and a capture-time structural and row inventory |
| Storage | Object bytes, bucket settings, paths, sizes and hashes |
| Edge Functions | Source files, deployment metadata and hashes |
| Configuration | Supported non-secret settings plus a list of manual settings |
| Secrets and API keys | Secret names and an external recovery source; new keys for the target project |
What happens when the source project is gone
Each accepted recovery point is stored in managed storage outside the source project. A new-project restore reads the stored artifacts and writes them to a separately selected empty target; it does not read customer data from the deleted source during that restore. The target must pass connection, version and emptiness checks before changes begin.
The database and Auth data are restored and compared with the saved inventory. Captured Storage files are restored and hash-checked, Edge Functions are deployed and compared, and supported non-secret settings are applied. Secret values, target API keys and external systems remain explicit manual actions rather than being reported as recovered.
The restore service enforces these boundaries itself, not the runbook around it. See the Supabase disaster recovery page for product coverage and the restore checklist for the complete incident sequence.