Sleep vs Pause vs Archive: Why Free Databases Fail Differently

Short version: "the free database went away" is three different events wearing one phrase. Sleep is a lifecycle state: the compute suspends on idle and comes back on your next query with nothing to click. Pause is a platform decision that stops the whole project and waits for a person. Archive is a deliberate reclaim that hands the data back only when you ask. The reason this matters is not vocabulary. It is that one of them surfaces as a slow first query, and another surfaces as an authentication error in your app, which is the last place you would look for a database problem.

Contents

• What developers are saying
• The bug that is not a bug
• Three different kinds of not running
• What CI jobs and coding agents actually need
• When a demo cannot afford a surprise
• If you are on a paused project today
• FAQ

What developers are saying

Quoted as written, spelling included.

• @the_codewala: "You sit there debugging for an hour just to realise that your superbase project has been paused this whole time"
• @DanielDani92400, in a longer post about free tools: "Supabase paused my DB mid-demo last week so I'm having trust issues with free tiers tbh"
• @heera0393, in a longer reply: "my Supabase free tier literally paused my database mid-demo last month"
• @FocusedMin56821, in a 3AM to 6AM log of a night shipping in public: "Supabase paused, auth broken"
• @Mindfull_Studio, in a longer post announcing their own app: "if you cant sign in, its because supabase paused the backend"
• @1234BellevueAve: "Nothing like opening your app and realizing supabase paused your project, again"

The bug that is not a bug

Start with the first of those, because it names the cost precisely: an hour of debugging, and the thing that was wrong was not in the code being debugged. That developer was not being careless. They were looking where the symptom pointed, and the symptom pointed at their own application.

Supabase publishes a custom HTTP status code for this. From their status code reference: 540 project paused, described as "The project the request was being made against has been paused. The project cannot process requests until it is un-paused by the owner."

Read that with a developer's eyes rather than a platform's. The unit that stopped is the project, and on Supabase the project is also your REST endpoint and your auth endpoint. So the first thing a person sees is not a database error. It is a login that fails, or a fetch that returns something your client code never handles. If you did not personally get the warning email, the reasonable first guesses are all wrong: a bad token, an expired key, a deploy that shipped a broken env var, a CORS change. "The database is off" is somewhere near the bottom of that list, because databases do not usually turn themselves off. Two of the posts above describe the symptom as broken auth, and one of them is an app's own author telling users that sign-in is down because the backend is paused.

When it happens is documented and not arbitrary. Supabase's project pausing guide says the platform "pauses Free Plan projects that show low activity over a 7-day period to save server resources," and that a project "is considered inactive if it does not receive sufficient user database activity over the past week." Getting it back is a person opening the dashboard and clicking Resume, and the restore window is one year.

The clearest evidence that this lands as a surprise is the tooling people build against it. supabase-pause-prevention is a small project, 178 stars as I write this, whose entire job is a scheduled task that makes a simple database call so the project stays active. There are GitHub Actions and uptime pingers doing the same thing. Nobody writes a keep-alive cron for a database that wakes itself up.

Three different kinds of not running

The three states differ on one axis that matters more than any other: what has to happen for the data to be reachable again.

Neon's numbers are from their scale to zero doc; paid plans there can turn the behavior off. Supabase's are from the pausing guide above. Ours are the free tier only: paid Layerbase plans never auto-archive, and a paid database you pin stays awake.

The middle two rows look similar on paper and are not. A sleeping database is a latency event your driver absorbs. An archived one is an outage until you ask for it back, which is why we only do it after two idle weeks and only on Free, and why the connection fails in a way that names the restore instead of hanging.

I wrote a vendor-by-vendor version of this table, including the tiers that expire on a calendar rather than on idleness, in every free database tier that sleeps, pauses, or expires.

What CI jobs and coding agents actually need

Neither has a human sitting in front of the dashboard.

A CI run creates a database, seeds it, runs the suite, and exits. An agent working through a task opens a connection between steps. Both of those tolerate a slow first connection fine. Neither can do anything at all with a state that requires someone to notice an email and press a button, and an agent will happily spend twenty minutes debugging your application code before it considers that the platform switched the project off.

Scheduled work is where this gets sharp. If your cleanup job lives inside the database as a pg_cron entry, the job's schedule is only meaningful while the database is running. Neon's pg_cron doc is direct about it: "pg_cron jobs will only run when your compute is active," with the recommendation to use it only on computes that run 24/7 or where scale to zero is disabled. That is easy to miss, because what you notice is the work that did not happen rather than the job that did not fire.

We do not offer pg_cron yet, and the import wizard warns you about this before you start rather than letting you discover it afterward. Schedule from your app or from CI, and the schedule stops depending on whether the database happened to be awake.

For per-pull-request work, a hibernated Layerbase database wakes on the first connection, and branching runs on 16 engines, so the branch your CI creates behaves the same way the parent does. That workflow, including TTL-bound throwaway databases that clean themselves up when a run crashes, is in a database per test run.

When a demo cannot afford a surprise

Sleep is the right default for a side project. It is the wrong default for the database behind something you demo on a schedule you do not control.

Solo is $5/month. It gets 2 databases, and the pool is sized so the one you pin never sleeps: pin the demo, let the second one sleep and wake like a free database. It also raises you to 100 concurrent connections and daily backups with 7-day retention. Pro is $15/month if you need more room or the heavier engines.

There is no meter under either of those numbers. Not compute hours, not per-branch billing, not egress. The whole price list is a short one, and the reason I keep it short is the same reason this post exists: a bill that depends on how much your database was awake is another thing you have to model before you can trust it.

If you are on a paused project today

The migration path is layerbase.com/migrate/supabase. You point it at your connection string and it copies the schema and the data.

The part worth knowing before you start is what the import report tells you afterward. It separates two things that get conflated: your own data that did not arrive, which is a real problem, and the platform machinery a plain managed Postgres does not ship, which is not. pg_cron, vault, and pgsodium are in that second group, along with the restore errors that exist only because those extensions are absent. An early real Supabase import landed all 39 customer tables and still reported "5 missing tables, 17 restore errors" before we taught it to tell those apart.

Two items in that group still need a decision from you rather than a shrug, and they are different decisions.

Vault and pgsodium hold secrets you have to carry over deliberately. Supabase manages a unique encryption key per project in their own backend, and their Vault documentation is explicit about what that means for a manual dump and restore: the new project "is created with its own fresh key and cannot decrypt secrets copied from the old project." So either pull the project's root key from their Management API before you cut over, or plan to re-create those secrets on the other side. Copying the ciphertext alone gets you nothing readable.

Scheduled jobs are a separate manual step. Copy your definitions out of the cron.job table before you cut over, and reschedule them from your app or CI.

Free is 2 databases and 5 GB with no card, which is enough to run the import and look at the report before you decide anything. Free is scoped to development, testing, evaluation, CI, personal projects, and early-stage products; once the thing you built is in production and earning recurring revenue, it belongs on a paid plan, which is what the Free plan is for. If you want the full feature-by-feature version rather than the lifecycle argument, that is the Supabase alternative writeup, and the two-vendor comparison is Neon vs Supabase.

FAQ

What is the difference between a database sleeping and a project pausing?

Sleeping is a compute suspending on idle and resuming on your next query, with no human step: Neon does it after 5 inactive minutes. We do it after 15 idle minutes on Free, 30 for MySQL and MariaDB, and after six idle hours on a paid plan unless the database is pinned always-on. Pausing is a platform-level stop of the whole project. Supabase pauses Free plan projects that show low activity over a 7-day period, and getting one back means opening the dashboard and clicking Resume. The practical difference is who has to be present for the data to be reachable again.

Why does a paused Supabase project look like an auth bug?

Because the thing that stopped is the project, not just the database, and the project is what serves your REST and auth calls. Supabase's own reference defines 540 project paused as the project being unable to process requests until the owner un-pauses it, so the symptom reaches your client as a failed request from the API layer. Checking tokens, env vars, and the last deploy first is the natural order, and all of it is wasted.

Do scheduled jobs run while a database is asleep?

Not if they live inside the database. Neon's pg_cron documentation states that "pg_cron jobs will only run when your compute is active" and recommends the extension only on computes that run 24/7 or with scale to zero disabled. We do not offer pg_cron yet, so the answer here is to schedule from your app or CI, where the trigger does not depend on the database being awake.

What happens to a Layerbase free database I ignore for a year?

It sleeps after 15 idle minutes and wakes on connect, a few seconds for most engines. After 14 idle days it archives (7 if it was never connected to), which drops the listener and needs an explicit Restore rather than waking on a connection. After 90 continuous archived days it offloads: the live resources are reclaimed and the most recent backup is kept and stays restorable, so the data is still there and still yours. Paid plans never auto-archive. The full state machine is documented at database lifecycle.

Can I keep one database always awake without paying for a meter?

Yes, that is what Solo is. $5/month, 2 databases, and the pool is sized so the one you pin stays awake while the other sleeps and wakes normally. Pro is $15/month for more databases and the heavier engines. Neither one adds a usage meter on top, which is the point of the price list.