The free tier of Supabase projects doesn’t just "pause" when inactive; it gets deleted after a period of inactivity, and you have to recreate it, not resume it.
Let’s see this in action. Imagine you have a Supabase project, my-awesome-app, running on the free tier. You’ve got a few tables, maybe some authentication set up. You deploy your app, and it’s humming along. Then, life happens. You get busy with other things, and your app goes quiet for a few weeks. No database queries, no auth requests, nothing hitting Supabase.
Here’s what Supabase’s free tier does:
-
Inactivity Detection: Supabase monitors your project for activity. This means active database connections, API requests, or any interaction through their SDKs. If there’s no activity for a certain period (typically 7 days), it flags the project.
-
Archival Notification: Before anything drastic happens, Supabase will send you an email. This email is your warning shot. It’ll say something like, "Your project
my-awesome-apphas been inactive and will be archived." Crucially, it will also state the timeframe for this archival – often another 7 days. -
Archival: If you still don’t re-engage your project within that second window, Supabase archives it. This means it’s no longer accessible via its API endpoints or the Supabase dashboard. Your data is not immediately purged, but it’s effectively offline and inaccessible.
-
Deletion: If an archived project remains inactive for an extended period (often another 30 days after archival, so around 45 days total inactivity), Supabase deletes the project and its associated data. This is the critical step. It’s not just paused; it’s gone.
What this means for you:
You can’t just log into the Supabase dashboard and click a "Resume" button. If your free tier project has been deleted due to inactivity, you need to create a brand new project. All your previous data, configurations, and settings will be lost.
The mental model:
Supabase, like many PaaS providers with free tiers, uses resource allocation strategically. Running a PostgreSQL database, an authentication service, and a real-time subscription server for every inactive project costs them money. To keep the free tier accessible to a wider audience, they need to reclaim these resources from projects that aren’t being used. Deletion is the most efficient way to do this. It’s not a punitive measure; it’s an operational necessity for their business model.
The levers you control:
- Activity: The primary lever is simply keeping your project active. This can be done by having your application interact with Supabase periodically. A simple background job that pings your API or runs a dummy query every few days can prevent archival.
- Notifications: Pay close attention to your email. The archival notifications are your last chance to save your project.
- Upgrading: If your project is critical and you can’t guarantee consistent activity, consider upgrading to a paid plan. Paid projects have much longer inactivity tolerances and, more importantly, are not subject to automatic deletion.
What most people don’t realize is that the "pause" is a euphemism for "deletion after a grace period." When you see an email about your project being "archived," it’s not a temporary state before it wakes up. It’s the first step in a process that leads to permanent data loss if you don’t act. Many developers miss these emails or underestimate the finality of the deletion, leading to the surprise of having to rebuild their entire backend from scratch.
The next problem you’ll hit is trying to access your project’s API endpoints after it’s been deleted, only to receive 404 Not Found errors or similar connection failures, with no clear indication in the Supabase dashboard that the project itself is gone.