You logged into the Supabase dashboard and your project is gone. Or it's there, but it says "Paused" and nothing connects. If you're in full panic mode right now and are seeing your free-tier Supabase project paused, the companion piece Supabase free-tier project paused: what to do (coming soon) walks through the immediate steps. This article covers the longer version: what actually happened, what's recoverable, what isn't, and how to make sure this doesn't happen a second time.
By the end you'll know exactly what state your project is in, whether your data is still intact, and what steps to take right now.
Paused vs. deleted: which one are you?
Before you do anything else, figure out which situation you're in. They look similar on the dashboard but the recovery path is completely different.
| Paused | Deleted | |
|---|---|---|
| Project visible in dashboard? | Yes (with "Paused" badge) | No (or greyed out) |
| Data intact? | Yes | Maybe, if within grace period |
| Can you self-serve recover? | Yes, one click | No, requires support |
| Time to recover | Minutes | Unknown, not guaranteed |
| Storage files intact? | Yes | Same grace period applies |
| Edge Function config intact? | Yes | Same grace period applies |
If you can still see the project in your dashboard with a "Paused" label, you're in the better situation. Your data is there; the project is just offline. Jump to the restoring a paused project section.
If the project is gone from your dashboard entirely, read the deletion section first.
What actually happens when a free-tier project is paused
Supabase pauses free-tier projects after roughly one week of inactivity [verify exact inactivity window]. "Inactivity" means no API calls, no database connections, and no logins to the dashboard. If nothing touched the project, Supabase takes it offline to reclaim resources.
Pausing is not the same as deleting. The underlying Postgres volume, the Storage bucket, and the Edge Function configuration all remain on disk. The project is frozen, not erased.
The catch: Free tier has zero days of backup retention, as documented in Supabase's backup overview. As we explain in how Supabase's native backup actually works, the daily snapshot that paid plans get doesn't exist on Free. So if you're hoping to roll back to a point before the pause, there's nothing to roll back to. What you get when you restore is whatever state the database was in when it froze.
What this means in practice
A paused project restores to the exact moment it was paused. If rows were deleted from a table two weeks ago and the project paused a week ago, those rows are gone. The pause preserved the current state, not a historical one.
What's recoverable after a pause (and what isn't)
Recoverable:
- All Postgres data that existed when the project paused
- Storage bucket metadata (the
storage.objectstable in Postgres) - Edge Function source code and configuration
- Auth users, API keys, project settings
Not recoverable after a pause:
- Any data deleted before the pause (nothing to roll back to on Free tier)
- Any schema changes you made and then reverted before the pause
One important nuance worth reading in detail: what Supabase's native backup doesn't cover explains that Storage object bytes (the actual file contents) live in a separate S3-compatible backend, separate from the Postgres volume. During a pause, Supabase keeps this backend accessible, so a simple resume restores everything. But if you were ever in a situation where you needed to restore Postgres from a backup to a point before the pause, the storage.objects metadata and the actual file bytes would be out of sync. That's the trap. For a basic pause-and-restore, you won't hit it. For anything more complex, know it exists.
The "restore project" button resumes your project from its paused state. It does not roll back anything. If data was lost or changed before the pause, restore does not undo that.
What happens when a project is deleted
Deleting a project is a different category of problem. You get a confirmation prompt before Supabase deletes anything, and most people who end up here clicked through it.
The good news: Supabase does not immediately erase the underlying data. According to their documentation on project deletion [verify exact path], there is a grace period after deletion during which support may be able to restore the project. The window is reported at around 90 days [verify], but this is not a published SLA and recovery is not guaranteed.
If you just deleted a project and need it back, open a support ticket immediately. Don't wait. The longer you wait, the lower the chance of recovery, and Supabase support will need the project reference ID, which you should note before the project disappears entirely from the dashboard.
What Supabase support can and cannot do in this situation: they may be able to restore the Postgres volume if it's still within the grace period and the underlying snapshot hasn't been purged. They cannot restore Storage file bytes from before the deletion if those weren't captured in a backup, and they cannot guarantee any particular recovery point. Recovery attempts are best-effort.
After the grace period, data is permanently gone. There is no further escalation path.
Step-by-step: restoring a paused project
If your project is paused and visible in the dashboard, the restore is straightforward.
1. Log into your Supabase dashboard at app.supabase.com.
2. Find your paused project. It will have a "Paused" badge on the project card. Click into it.
3. Click "Restore project." Supabase will show a prompt confirming the restore. Confirm it.
4. Wait for the restore to complete. For small projects this usually takes two to five minutes [verify]. Larger projects may take longer. The dashboard will show progress.
5. Verify your data. Once the project is back online, open the Table Editor or connect via your normal client and confirm your data looks correct. Check a table you know well.
6. Test your connections. If your application was connecting with a connection string from the dashboard, verify it still matches. Supabase does not change connection strings on resume.
If the restore fails or the project doesn't come back online within ten minutes, open a support ticket. Include the project reference ID and the timestamp when you started the restore.
How to prevent this next time
The most direct fix is upgrading to Pro ($25/month). Pro plans don't get paused for inactivity. If budget is the issue, the other options are cheaper but require a bit more setup.
Keep the project active automatically. A simple cron job that pings your Supabase API endpoint every few days is enough to keep the inactivity timer from expiring. A lightweight health check from any CI/CD system or monitoring tool works too.
Take an off-site backup before you hit the limit. The proactive backup approach, covered in detail in how to back up Supabase Postgres (coming soon), comes down to running a pg_dump on a schedule and storing the output somewhere you control. Here's the one-liner to run right now, before you do anything else:
pg_dump "postgresql://postgres.[YOUR-PROJECT-REF]:[YOUR-PASSWORD]@aws-0-[REGION].pooler.supabase.com:6543/postgres" --format=custom --file="supabase-$(date +%F).dump"
Replace [YOUR-PROJECT-REF], [YOUR-PASSWORD], and [REGION] with the values from your Supabase project settings under "Database" > "Connection string." The --format=custom flag produces a binary format that pg_restore can handle efficiently. Store the output file in an S3 bucket or anywhere outside your local machine.
The full manual backup guide on this blog has the complete script version with error handling and scheduling.
What to do next
If your project is paused right now: restore it using the steps above, then set a calendar reminder to either upgrade to Pro or set up that activity ping.
If your project was deleted: open a support ticket immediately, include your project reference ID, and don't spin up a new project in the same organization under the same name before they respond (it can complicate the recovery).
If you're reading this before anything went wrong: that's the best time to act. Run the pg_dump one-liner above, put the file somewhere safe, and consider whether Free tier is actually the right plan for a project you care about.
If scripting and scheduling your own Supabase backups sounds like a second job, SimpleBackups handles Supabase Postgres and Storage backups off-site, with alerts when a run fails. See how it works →
Keep learning
- How Supabase's native backup actually works
- What Supabase's native backup doesn't cover
- How to back up Supabase Postgres (coming soon)
- The complete Supabase backup guide
FAQ
How long before Supabase pauses an inactive free-tier project?
Supabase pauses Free tier projects after approximately one week of inactivity, defined as no API requests, database connections, or dashboard logins [verify exact window]. The exact threshold is not documented with an SLA, but one week is the commonly reported figure. Keeping the project active with any periodic request resets the timer.
Can Supabase support recover a deleted project?
Possibly, if you act quickly. Supabase keeps deleted project data for a reported grace period of around 90 days [verify], during which support may be able to restore it. Recovery is not guaranteed and depends on whether the underlying data has been purged. Open a ticket immediately and include your project reference ID.
Do I lose my Storage files when a project is paused?
No. Storage files are preserved during a pause. When you restore the project, your Storage bucket contents come back along with your Postgres data. However, if you were restoring from a backup rather than just resuming a pause, Storage file bytes are not included in the native Postgres snapshot, which is a separate issue covered in our guide on what Supabase's native backup doesn't cover.
What's the difference between pausing and deleting a Supabase project?
Pausing is automatic and reversible. Supabase pauses inactive Free tier projects to reclaim resources, but the data stays on disk and you can restore the project yourself in minutes. Deleting is a manual, destructive action you take intentionally. Once deleted, recovery depends on Supabase support and is not guaranteed.
How do I set up automatic backups to prevent this?
The quickest path is a scheduled pg_dump piped to an S3 bucket, covered in the Supabase Postgres backup guide (coming soon). The full script with error handling and rotation is in how to back up Supabase. If you'd rather not manage the scheduling yourself, SimpleBackups handles it automatically with scheduling and failure alerts.
This article is part of The complete guide to Supabase backup, an honest, practical reference from the team that backs up Supabase every day.