Supabase pauses free projects after a week without activity

The workload

Supabase documents a Free-tier inactivity rule across two of its own pages, and the workload for a founder is to reconcile the two, since the trigger window is stated slightly differently in each. The pricing page, retrieved 16 September 2026, states free projects are paused after 1 week of inactivity. A separate production-readiness guide, retrieved the same day, states Supabase may pause Free Plan applications that exhibit low activity in a 7-day period to save server resources. A founder running a Free project has to keep it active, or know how to restore it, rather than assume it runs indefinitely once created.

What the documents show

Verified: both documents describe the same window, one as 1 week and the other as 7 days. Verified: the production-readiness guide states a paused project can be restored from the dashboard, and that upgrading to Pro removes the pausing behaviour entirely, consistent with a companion entry's finding that Pro projects never pause. Verified: the same guide states, as a separate limitation rather than a stated consequence of pausing, that database backups are not available for download on Free. The documents do not state that pausing itself causes data loss; that question is simply not addressed either way.

The operating cost

Verified: there is no direct dollar cost tied to pausing; a Free project remains $0 per month whether or not it has been paused. Estimated: the real cost is operational, restoring a paused project from the dashboard and re-establishing any external connections, a task the documentation confirms is possible but does not quantify in time. Avoiding pausing entirely means moving to Pro, which a companion entry states costs $25 per month plus compute, a cost some founders may not want for a project that is legitimately inactive.

The stop condition

The documentation gives a clear operational stop condition for the pausing behaviour itself: a project that stops being paused, permanently, once it moves to Pro. Editorially, for a project still on Free, the more useful stop condition is about intent rather than plan tier: if a project is being kept alive only to avoid the pause, rather than because it is serving real traffic, that is a signal the project has either finished its purpose or needs to be evaluated for whether it belongs on a paid tier, since the Free tier's own documentation frames it as intended for exploration rather than for indefinite unattended uptime.

• Is this project's actual usage pattern genuinely low-activity, or does it need to be reachable on a schedule the 7-day window doesn't accommodate?
• Has restoring a paused project from the dashboard actually been tested, or is that step being assumed to work when needed?
• Does the stated unavailability of downloadable backups on Free change whether this project's data should live there at all?

Two Supabase documents describe the same rule in different words but do not disagree; read together they establish the trigger, the fix, and one adjacent limitation (no downloadable backups) that a founder should not conflate with the pausing rule itself.