Supabase project paused: why it happens and how to unpause it

Supabase pauses Free plan projects after a 7-day stretch of low activity. Your data is not deleted and you are not billed — the project is switched off. To bring it back, open the dashboard, select the paused project, and click Resume project. You have 1 year to do that, not 90 days.

Below: the full clock, the resume steps and where they fail, what to do if the year already ran out, and the one measure that makes a pause stop mattering.

Why Supabase pauses free projects

Pausing is a capacity measure. Most free projects go quiet — a tutorial finished, a prototype parked, a client demo that shipped a year ago — so Supabase pauses those showing low activity over a 7-day period rather than keeping compute running for nobody. Paid-plan projects are never auto-paused.

What counts as activity is broader than people expect. Per the official docs, database queries, API calls, requests from an application connected to the project, and simply visiting the project in the Supabase Dashboard all register. Supabase’s own guideline is that a few user requests to the database each day over the previous week keeps a project awake. So a live app with real users effectively never pauses. What gets paused is the thing you stopped looking at — which is exactly the thing whose data you would most struggle to reproduce.

Two details that head off the usual worries. Paused projects are not billed— no compute, no compute charges. And they stop counting toward the Free plan’s limit of two active projects, which is why pausing an old project is the supported way to free up a slot.

How to unpause your project

Resuming is four clicks:

1. Open the Supabase Dashboard.
2. Select the organization that owns the project, then the paused project itself.
3. Click Resume project.
4. Confirm. Restoration takes a few minutes for a small database and longer for a large one.

The project returns to its previous state, data and configuration included. Three things commonly go wrong at this step:

You are already at two active projects. The Free plan allows two running at once, and the count is not per-organization: it spans every organization where you are an Owner or Administrator, and within an organization it aggregates across all of its Owners and Admins. So the project occupying your slot may be in a different organization entirely, or belong to a collaborator. Pause or delete one that counts toward the limit — wherever it lives — then resume the one you want.

The restore itself fails. Most likely on a project that sat paused a long time: Supabase notes that a backup taken outside the backwards-compatibility window may fail to restore, since the platform moves on while your project does not. That is a support ticket, not something to retry — and a reason not to leave a resume for next month.

There is no Resume button at all. That means the in-place restore window has closed — covered two sections down.

The deadline: what actually happens to your data

The pause itself takes a snapshot, and that snapshot is what a resume replays. The clock that follows is the part worth knowing precisely:

Everything above the last row is recoverable by clicking; below it there is no recovery path inside Supabase at all. Deleting a project is documented as permanent — database, Storage files, automated backups, and any PITR snapshots go together. Be precise about what is documented, though: Supabase publishes the one-year resume window and the download path that follows it, and documents deletion as permanent — it does not publish a schedule that deletes long-paused projects for you. So the honest framing is not a countdown. It is an unmanaged dependency: data you have stopped watching, held under terms that can change, with recovery that gets harder as the platform moves on. Worth fixing whether or not anything ever gets deleted.

What about the 90-day rule you read about?

It is out of date, and the confusion is Supabase’s own doing. The official troubleshooting article on this still lives at a URL ending in restore-project-after-90-days-pause, so a search for a paused project surfaces the number 90 everywhere — in the link, in older blog posts, in every Reddit thread written before the change. Open the page and the text says something different: projects paused for more than 1 year can no longer be restored through the dashboard.

Practically: if your project paused eight months ago, ignore the 90-day panic and go resume it. If it paused fifteen months ago, the next section is for you. And if you are reading this because a search result said 90 days — verify the number against the pausing docs before acting on it. Retention numbers move; this one moved in your favor.

How to restore a project paused past the window

Two routes, and the first one is easy to miss. Upgrading the paused project to a paid plan re-enables expired one-click restore options, so the resume button can come back for the price of one month of Pro. The caveat is in the same docs: a backup taken outside the backwards-compatibility window may fail to restore anyway, and Supabase points you at Support when it does. Try this before anything manual.

If that does not work, the project is still readable until it is deleted, and recovery becomes a migration into a fresh project: download the .backup database file and every Storage bucket from Project Overview, restore the database into a new project, copy the Storage files up with the CLI, and re-apply project settings. Supabase’s troubleshooting guide has the commands, and its dashboard restore page covers the parts that trip people up — the file may arrive gzipped, the errors about auth and storage already existing are expected, and a Postgres 15 or older psql can fail against the Session pooler with a GSSAPI error, so use a current client. Follow their procedure rather than a transcription of it; it is maintained against a platform that changes. Our restore guide covers the two steps people get stuck on — telling which format the .backup file is in so you reach for psql or pg_restore correctly, and pushing the downloaded Storage files back up with the CLI.

Three things worth knowing before you start, because they are the ones that turn a long afternoon into unrecoverable data.

The encryption root key has to be copied while the project is still running. If this project uses Vault or any encrypted column, a new project gets its own key and cannot read data encrypted under the old one — and the Management API returns that key only for active projects. A paused project will not hand it over. So resume first (upgrading counts), copy the key, and only then migrate. If resume is impossible, that data may be permanently undecryptable, and finding out now beats finding out after rebuilding everything else.

Auth users arrive through the errors you are told to ignore. The duplicate-object messages about auth are expected, but that is also the schema carrying your user accounts. When the restore finishes, count rows in auth.users and in two tables whose size you already know, before trusting any of it.

The application has to be cut over, not just the data. The new project has a different URL and different API keys, and none of the Auth configuration travels — providers, redirect URLs, email templates and the JWT secret are project settings, not database rows. Existing sessions will be invalid, and OAuth redirects pointing at the old project ref need changing at the provider too.

Unlike the resume button, none of this is destructive to the source project: if a restore goes wrong you still have the downloaded files and can start the target again. Take the download step today even if you rebuild next week — Supabase publishes no deletion schedule, and older backups get harder to restore as the platform moves on.

How to keep a project from being paused

The obvious approach works: keep enough real traffic on it. Supabase describes the trigger as low activity over a 7-day period rather than publishing a precise threshold, and its guideline is a few database requests a day — so aim comfortably above one, not exactly at it. Where there are no real users, teams add a scheduled ping — a cron job or a GitHub Actions workflow hitting an endpoint that actually queries the database. Match it to the guideline rather than the minimum: a few requests spread across each day, not a single one that has to land perfectly. A request that never reaches Postgres does not count at all.

Be clear about what that buys you. A keep-alive ping prevents one failure mode — the pause — and no others. It does not help when a migration drops a column, when someone runs a DELETE without a WHERE clause, when a compromised key wipes a table, or when the project is deleted outright. It is also one more thing that can silently stop working; a paused cron job protecting a project against pausing is a fitting way to lose data.

Upgrading to a paid plan removes auto-pausing entirely, and adds daily backups kept 7 days. Both are real improvements. Neither puts a copy of your data anywhere other than Supabase.

The fix that outlives the project

Every path on this page ends at the same place: the data has to exist somewhere that is not the paused project. A pause is a warning shot — a loud one, since the project is unreachable and you notice immediately. Deletion after the window is the quiet version, and there is no recovery path from it.

A weekly dump into a bucket you own turns all of this into housekeeping. You can do it yourself for free: the GitHub Actions guide has a complete scheduled workflow, and the free plan guide covers the two-minute manual version for right now. BackupDrill’s free plan does the same on a schedule for one project — into your own S3, R2, or B2 bucket, never our disks — and restore-tests the first backup so you find out it actually restores before you need it to.

A paused project is data you have stopped watching, on terms somebody else sets. A snapshot in your own bucket is neither.

FAQ