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

"The free tier goes to sleep" is used to describe three completely different things, and only one of them is sleep. A Postgres compute that suspends after five idle minutes and wakes on your next connection is not the same product as a project that pauses after a week and stays down until a human opens a dashboard, and neither one is the same as a database that gets deleted 44 days after you created it no matter how much you use it.

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 as of August 2026 and are linked inline.

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. 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 60 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 one database 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 it 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.

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.