What Happens When a Free Database Pauses

Every free hosted database is paid for somewhere, and on a free tier part of the price is availability. Supabase pauses a Free Plan project that has been quiet for a week. For a side project that is a fair trade: a real Postgres database at no cost, in exchange for the provider stopping a server nobody is using. For anything a person depends on, the same behaviour is an outage with a warning email attached.

The useful question is not whether pausing is good. It is what pausing does, and what has to be in place before it happens. The practices below keep a pause an inconvenience instead of an incident.

What pausing actually does to a project

A paused project is not asleep the way a laptop sleeps. The database stops answering, and the project is unusable until someone resumes it. The state survives: Supabase's pausing guide says a resumed project returns to its previous state, including data and configurations.

The return is a platform operation, not a switch. The upgrading guide notes that Free projects move to the latest minor Postgres version when restored. The database you get back may not be identical, and a restore is not a wake-on-LAN.

When Supabase pauses a Free project

In its documentation, Supabase says it pauses Free Plan projects that show low activity over a 7-day period to save server resources. A project counts as inactive when it does not receive sufficient user database activity over the past week. The guide is deliberately vague about the threshold, then gives a practical rule: typically a few user requests to the database each day over the previous week are enough to keep the project from being paused.

Two details matter more than the number. The activity is database activity, so a dashboard with no queries is a candidate. And your own use may not be enough: the guide warns that usage can be too low even while you are working on the project. Paid plans are not paused for inactivity.

The warning arrives before the pause

Supabase sends two emails to the project owner: a warning roughly one week before the pause takes effect, and a confirmation once the project has been paused. During the warning window the pause can still be prevented by visiting the project in the dashboard or by making API calls to it.

That email is the real deadline, not the seven-day clock. It goes to the project owner, not to every member of the organization, so check that the address is one a person reads. We treat the warning as the point where a project gets activity or gets moved.

Getting a paused project back

The documented path is in the dashboard: open the organization, select the paused project, click Resume project and confirm. There is no separate procedure to learn. The guide does not state how long a resume takes, so we do not quote one. If the project matters, treat the resume as an operation that needs a person and a check afterwards.

After the resume, verify three things: the application connects, the rows you expect are present, and any scheduled job pointed at the database has caught up. A pause does not queue work. A webhook that fired while the project was offline failed.

The restore window is documented with two numbers

Here the documentation is internally inconsistent, and the inconsistency matters because it is the difference between planning for a quarter and planning for a year.

The body of the pausing guide says you can restore a paused project for up to 1 year after it was paused, and the restore window section repeats that there is a 1-year window to restore the project. The anchor for that same section is 90-day-window-to-restore. Supabase's own changelog from June 2024 announced that paused Free projects are restorable for 90 days following their pause date. The knowledge-base page on recovering an expired project has a slug ending in restore-project-after-90-days-pause while its title says more than 1 year.

The one dated statement is the 90-day changelog. The 1-year figure appears in the current body text, but its own anchor was not updated.

Our advice is to plan on the shorter period. Ninety days is the number you can act on without waiting for the documentation to agree with itself, and a project paused for a quarter unnoticed has a different problem. Treat one year as a possible extension, not a deadline.

What happens at the end of the window is documented. The restore option is replaced by an option to download the latest logical backup, taken right before the project was paused, together with all Storage objects. Once the project is deleted, all associated data including backups is permanently removed and cannot be recovered. The guide explains why: backups are only retained for a limited period, and platform changes may not be backward compatible with older ones. A paused project's static backup cannot be updated to follow those changes.

The backups guide describes daily backups for Pro, Team and Enterprise only, and recommends that free tier projects regularly export their data with the Supabase CLI db dump command and keep off-site copies. A database backup also does not include objects stored through the Storage API; those need to be copied separately.

If you are on a free tier, whichever provider

Supabase is the example here because its documentation is public and specific, but the shape is common. A free tier that stops idle resources will stop yours. Four practices cover most of the risk, and none of them depends on which logo is on the dashboard.

Keep a dump you can restore somewhere else

The point of a dump is portability, not storage. A logical dump restores into any compatible Postgres, on any provider or on your own machine. We wrote about the discipline of testing a backup before you need it, and it applies here unchanged.

With Supabase, supabase db dump runs pg_dump and leaves out the internal schemas. One command is not a complete backup: the CLI reference says the default dump does not contain any data or custom roles, and the ignored schemas include auth and storage. A useful set is a schema dump, a data dump with --data-only, a role dump with --role-only, and a separate copy of the files in Storage. Write them outside the provider, keep more than one generation, and restore the newest into a scratch database from time to time. A dump that has never been restored is a guess.

If the project has already passed its restore window, the knowledge-base guide still offers a way out: download the backup and the Storage objects, create a new project, and load the file with psql. Supabase also documents restoring a downloaded backup locally with supabase db start --from-backup. The guide warns that a CLI database is not production ready. That is a recovery path for inspection, not a hosting plan.

Keep the project awake, or keep a check that tells you it stopped

These are different jobs, and it is easy to buy one thinking it is the other. A keep-alive is a scheduled request that counts as database activity: a small query through the API once a day is the documented kind of traffic. A check is a request that fails loudly when the project stops answering, with an alert that reaches a person.

A keep-alive has its own failure mode: the scheduler is now part of your stack, and if it stops, the project pauses quietly. A check without an alert is not a check. If the project must answer when nobody is watching, a free tier is the wrong host: the pause is a feature of the plan, not a bug you configure away.

Know the warning channel

Find out which address receives the pausing email, and make sure it is one a person reads. On Supabase it is the project owner. If that person has left, or the address is a no-reply alias, the first warning you get is the outage. Add a recurring calendar note for the point where a quiet project would be paused, and check the dashboard status when a project has been untouched for a while. The warning is a courtesy, not a guarantee: filters, forwarding rules and changed addresses all break it.

Decide in advance when the project stops being a side project

Write the trigger down before you need it. The project has crossed the line when someone other than you depends on it, when it holds data you cannot rebuild, when it takes money or carries a legal obligation, when a client will see it at a stated time, or when it has to answer outside your working hours. Any one of those is enough.

Moving to a paid plan removes the pause: Supabase states that projects on paid plans are not paused for inactivity. The pricing page lists the Free plan at $0 with 500 MB of database size per project and a limit of two active projects, and Pro from $25 per month. The subscription is not the whole cost: compute is billed per project on an hourly basis, and disk and egress have included quotas with per-unit prices after that. The decision is not free versus $25. It is whether keeping a free project alive costs less than a bill that grows with use.

What each choice costs

• Stay free and accept the pause. No subscription. The cost is an outage of unstated length every time the project goes quiet, plus a restore that may move the database to a newer minor version. Your recovery time is your detection time.
• Stay free and keep it awake. A scheduler, a query a day and a monitoring alert. The cost is attention and one more moving part that can fail silently. Fine for a demo, thin for a service with users.
• Move to paid. A recurring subscription plus usage-based compute, disk and egress. In exchange the pause disappears, and the plan includes daily backups retained for seven days, which shortens a different kind of outage.

We would not put a figure on the first two. They are paid in hours, at whatever an hour of downtime costs you.

Where we land

Free pausing is a sensible default for a project that is still an experiment. It is a poor fit for anything that has stopped being one. The line is crossed earlier than most people admit, usually at the moment a second person starts relying on the thing.

If you stay on the free tier, do the boring parts now: a dump you have restored once, an alert that reaches you, the warning address checked, and a written trigger for moving to paid. Those four turn a pause from an emergency into a maintenance task. If the project already matters, pay for it and spend the attention on the application, not on keeping the host from switching it off.