Every Free Database Tier That Sleeps, Pauses, or Expires - and What Staying Awake Actually Costs

Short version: "the free tier goes to sleep" describes three different products and only one of them is sleep. Sleeping is a compute that suspends after a short idle window and comes back on your next connection with nothing to click, which is what Neon does at 5 idle minutes and what we do at 15. Pausing needs a human: a Supabase free project with under a week of activity goes down and stays down until someone opens the dashboard and clicks Resume. Expiring ignores idleness entirely: Render deletes a free Postgres 30 days after you created it, plus a 14-day grace, no matter how much traffic it served. Sleeping is fine. Pausing is an outage nobody is watching. Expiring is a trial with the label filed off.

Contents

• The three failure modes
• What always-on costs, per provider
• The keep-alive industrial complex
• Sleeping is not the failure. Not waking up is.
• Where we land, including the parts that are not flattering
• FAQ
• Where to start

All three get filed under "free tiers are unreliable," which is unfair to the first and far too generous to the third. Here is the taxonomy, the trigger for each, and the actual monthly price of the cheapest always-on configuration on each platform. All figures are from public docs and pricing pages, linked inline, and the rates were verified 2026-08-25 from neon.com, supabase.com, render.com, aiven.io and planetscale.com.

The three failure modes

Sleeps. The compute suspends after a short idle window and comes back on the next connection with nothing for you to click. Neon's plans doc is blunt about the free version: "Free: 5 min inactivity; cannot disable." That last clause matters more than the five minutes. Scale-to-zero is not a setting on the Free plan, it is the plan. Koyeb auto-sleeps its free Postgres after five idle minutes too. Your data is untouched and the cost is a cold start.

Pauses. Recovery requires a person. Supabase's docs define an inactive free project as one that "does not receive sufficient user database activity over the past week," and note that "a few user requests to the database each day over the previous week is enough to keep the project from being paused." Getting it back is a manual sequence: open the dashboard, select the organization, select the paused project, click Resume project, confirm. The data survives, with a 1-year window to restore from Studio, though their docs are honest that backups are retained only for a limited period and an old one may not be compatible with the current platform, so the practical window is shorter than the nominal one. What does not survive is availability. An unattended project stays down until someone logs in, which is exactly the case a staging environment or a demo link is unattended.

Expires. The clock is not about idleness at all. Render cut free Postgres expiry from 90 days to 30, measured from creation. After it expires you get "an additional 14 days to upgrade it to a paid instance type before your data is deleted." Two pieces of folklore to correct here, because I still see both in comparison posts: it is 30 days, not 90, and it is calendar-based, not inactivity-based. A cron job hammering that database changes nothing about the countdown. The free tier docs add the parts that matter if you were considering it for anything real: 1 GB of fixed storage, no managed connection pooling, one free database per workspace, and "Free Render Postgres databases don't support any form of backups."

Worth separating, since it causes real confusion: Render's free web services spin down after 15 minutes of no traffic and take about a minute to come back. That is a sleep, in the first category. The Postgres expiry is a different mechanism on the same platform, and people who have only experienced the first one are often surprised by the second.

What always-on costs, per provider

The Neon number is the one people are surprised by, so here is the arithmetic rather than an adjective. Free cannot disable scale-to-zero, so "always-on" means moving to Launch, which bills pure usage with no monthly minimum. Compute is $0.106 per CU-hour. A single 1 CU compute held on through a 730-hour month is about $77 of compute, before $0.35/GB-month of storage. That is not a criticism of Neon's pricing. Holding a CU means holding the RAM, and RAM held is RAM paid for. It is simply what the words "never cold" cost when the meter is honest.

Aiven deserves credit as the counterexample. Their free Postgres has no time limit and no scheduled pause, at 1 GB storage, 1 GB RAM, and 1 CPU on a single node. The caveat is in their platform docs rather than the landing page: Aiven reserves the right to power off free services with no continuing activity, with a notification first, and you can power them back on. Small, honest, and the closest thing on this list to a free database that just sits there.

The keep-alive industrial complex

If pausing were a minor inconvenience, nobody would have built tooling for it. Instead there is a small industry whose entire product is manufacturing fake activity.

supabase-pause-prevention is a Supabase edge function whose only job is to write a row on a schedule so the project reads as alive. It has 174 stars, which is 174 people who cared enough to bookmark a workaround for a database they are not paying for. The hibernot npm package does the same job as a dependency. Runhooks published a guide to preventing free-tier pausing and sells the scheduler that runs it. Tell Me When Down has a whole post on why projects pause and how to keep them awake. Underneath all of it is the folk version: a GitHub Actions cron that curls an endpoint every six hours.

Look at what that loop actually does. The vendor pauses idle projects because idle compute costs real money. The user answers with a synthetic query every few hours. The compute is now never idle, so the vendor pays more than they would have paid for an honestly idle project, and the activity signal they were using to identify abandoned work now measures nothing but cron jobs. Both sides spend money to arrive back where they started.

The keep-alives are also fragile in a way that is almost too on the nose: GitHub disables scheduled workflows after 60 days of repository inactivity. The cron job that exists to stop your database from falling asleep falls asleep first, on the same reasoning, and the first sign is a paused project two months later.

Sleeping is not the failure. Not waking up is.

Scale-to-zero is a good mechanic and I want to defend it, because the backlash against pausing keeps catching it by accident. A database that suspends when nobody is using it and resumes on the next connection costs the vendor almost nothing to carry, which is precisely why that vendor can keep offering it next year. The alternative model, an always-running process per free account, is the one that gets repriced or retired.

The useful test is not "does it sleep." It is three other questions:

1. Does it come back without a human? Wake-on-connect is a slow first query. A dashboard button is an outage that lasts until someone notices.
2. Is the clock measuring idleness or the calendar? An idle timer is a deal you can influence. A 30-day expiry from creation is a deadline, and no amount of traffic moves it.
3. What survives the worst case? Supabase keeps your data restorable for a year. Render deletes it at day 44 and, on the free tier, has no backups to fall back on.

Rank the list by those three and the ordering changes a lot. The five-minute sleepers come out fine. The pause is a real operational problem. The expiry is a different category entirely, and it belongs in the "trial" column rather than the "free tier" column.

Where we land, including the parts that are not flattering

I build Layerbase, so check these rather than taking them from me.

Our free tier is $0, no card, 2 databases, 5 GB of storage, across 8 engines. A free database hibernates after 15 idle minutes and wakes on the next connection in roughly 1-5 seconds, with nothing to click. That puts us in the first category, not the second or the third.

Now the part a marketing page would leave out. Free databases do not sleep forever untouched. After 14 days hibernated, a free database is archived (7 days if it was never connected to at all), and archived is a real state change: the listener and DNS are released, and getting it back takes an explicit Restore click that runs about 10-30 seconds. We send email at day 0, day 75, and day 89. At 90 continuous archived days the database is offloaded: the live resources are reclaimed, and the most recent backup is kept, downloadable, and one click from restored. We never prune a last backup, so this is not the Render outcome, but it is also not "free and always warm."

So I am not going to claim we are the always-on free tier. Nobody honest on this list is. What we are is the cheapest always-on rung: Solo is $5/month for two databases, one of them pinned always-on out of a 768 MB reserved pool, with 10 GB, 10 engines, and daily backups on 7-day retention, and no archive pipeline touching either of them at all. Pro is $15/month for up to 10 databases, 25 GB, every engine we host, 30-day rolling backups, and never archived. Both are flat. There is no meter on queries, connections, rows read, or egress on any plan, including the free one.

Put next to the always-on column above, that is $5 against $25 on Supabase Pro and against roughly $77 of Neon compute. That gap is not cleverness on our part, it is a difference in what is being sold: Supabase Pro buys a whole backend platform, and Neon's price buys autoscaling and branching on a storage engine built for it. If those are what you need, pay for them. If what you need is a Postgres that answers at 3am for a side project, $25 and $77 are both a strange amount of money for that.

FAQ

What is the difference between a database that sleeps and one that pauses?

Whether getting it back needs a person. A sleep is a compute suspend that reverses on your next connection, so the cost is a slow first query and nothing else. A pause is a state change that waits for someone to open a dashboard and click Resume, which means an unattended staging environment or a demo link stays broken until somebody notices. Same words in the marketing copy, completely different operational risk.

Does a free Postgres actually get deleted?

On Render, yes, and the clock has nothing to do with idleness. A free Postgres expires 30 days after creation, then you get 14 more days to move it to a paid instance type before the data is deleted. A cron job hammering it changes nothing. Everywhere else on this list the data survives: Neon suspends compute, Supabase pauses the project, Aiven powers the service off after emailing you, and we archive with the most recent backup kept and restorable.

Can I stop my free Neon database from sleeping?

No. Their plans doc puts it in four words: "Free: 5 min inactivity; cannot disable." Scale-to-zero is not a setting on the Free plan, it is the plan. Always-on means moving to Launch, which is pure usage billing with no monthly minimum.

What does an always-on free-tier replacement actually cost?

More than people expect on a meter and less than people expect on a flat plan. Holding a single 1 CU Neon compute on through a 730-hour month is about $77 of compute at $0.106 per CU-hour, before $0.35 per GB-month of storage. Supabase's paid tier is $25 a month. Our Solo plan is $5/month and pins a database always-on out of a 768 MB reserved pool. Those are three different products, not three prices for one product, so pay for the one you actually need.

Should I run a keep-alive cron job?

It is a bad deal for everyone involved, and it breaks in a way that is almost too neat. The vendor pauses idle projects because idle compute costs money; you answer with a synthetic query every few hours; now the compute is never idle and the vendor pays more than an honestly idle project would have cost. Then GitHub disables scheduled workflows after 60 days of repository inactivity, so the cron that exists to stop your database falling asleep falls asleep first, and you find out two months later.

Which free tier is safest for a staging database?

One that sleeps rather than pauses or expires, because staging is unattended by definition. Ranked by the three questions that matter (does it come back without a human, is the clock measuring idleness or the calendar, and what survives the worst case) the five-minute sleepers do fine, the pause is a real operational problem, and the 30-day expiry belongs in the trial column rather than the free-tier column.

Where to start

If your free tier is currently kept alive by a cron job, that is your answer about whether it fits. Start a free database, or read the pricing first. The longer version of why our free tier is built to survive, sleep included, is in the free tier that stays.