Dora NodaYour database has an expiry date. Your app doesn't. That is the whole gotcha with Render's free tier, and it is stated plainly in Render's own docs: free web services are free forever, but a free Postgres database expires 30 days after creation.
The timeline is exact — day 0 you create the database, day 30 it goes inaccessible, a 14-day grace period opens in which you can still upgrade it to a paid plan, and on day 44 Render deletes the database along with all of its data. Render emails you at both edges, but an email is not a plan.
This bites in the most ordinary way possible. You prototype in week one, share the link in week three, get busy, and come back in week six to a live app connected to nothing. Every database-backed side project on Render's free tier is therefore a 30-day decision wearing a free-forever costume: start paying, migrate the data, or lose it. This post prices all three doors — with Render's official numbers, a 12-month view, and the honest ops cost of the exit — so you can decide before the clock does it for you.
What expires and what doesn't
The asymmetry is the point, so here it is side by side, straight from the free-instances documentation:
| Free web service | Free Postgres | |
|---|---|---|
| Price | $0 forever (750 instance-hours/month) | $0 for 30 days |
| Capacity | 512 MB RAM, shared CPU | 1 GB storage, one instance per workspace |
| Idle behavior | Spins down after 15 min idle, ~1 min to wake | Always on until it expires |
| Persistence | Ephemeral filesystem; no persistent disks | Persistent — until day 30 |
| Safety nets | Rollbacks to last 2 deploys | No backups, no connection pooling |
| After the limit | Suspended until next month (hours) | Inaccessible; deleted after 14-day grace |
Two details deserve emphasis because they close off the obvious workarounds. First, you cannot dodge the database expiry by keeping data in the app: free web services have an ephemeral filesystem and cannot attach persistent disks, so a local SQLite file dies on every redeploy, restart, or spin-down. Second, the free Key Value (Redis) instance is in-memory only — a restart wipes it. On Render's free tier, all state is provisional; Postgres is just the one with a calendar date attached.
One more note for anyone cross-checking against blog posts and READMEs: some older community guides say free Postgres lasts 90 days. That figure is stale. The current official docs say 30 days plus a 14-day upgrade grace period, and the docs are what the dashboard enforces.
Day 31: three options, priced
Assume a typical side project: one small web app plus one Postgres database under 1 GB. Here is what each door costs, monthly and over 12 months:
| Option | Monthly | 12 months | What you get |
|---|---|---|---|
| A. Stay, pay for the DB only | ~$7 | ~$84 | Sleepy free app + Starter Postgres (backups, pooling, no expiry) |
| B. Stay, always-on app + DB | ~$13–14 | ~$160 | Starter web service ($7) + Starter Postgres (~$6–7), never sleeps |
| C. Split: free app + external free DB | $0 | $0 | Render app + Neon/Supabase free Postgres; two vendors, two failure domains |
| D. Leave: app + DB on one flat-rate box | ~$6.92 | ~$83 | Hetzner CX23 (2 vCPU, 4 GB RAM, 40 GB disk); everything always on |
The numbers behind the table: Render's cheapest paid Postgres (Starter/basic tier) runs about $6–7 a month for 1 GB storage with 7-day backups, and a Starter web service is $7 a month — consistent with Render's own "starter web + basic Postgres ≈ $13/month" figure before storage growth. The Hetzner CX23 lists at €5.49/month (about $6.92) for 2 vCPU, 4 GB RAM, and 40 GB of disk, with the 4 vCPU/8 GB CX33 one step up at about $10.38.
Option C looks like free money until you read the fine print in both directions. The external database adds cross-provider latency to every query, and Render's docs warn that a free web service initiating "an uncommonly high volume of traffic" — which explicitly includes accessing an external database — can be suspended, restorable only by moving to a paid plan. You have also split your project across two vendors' free tiers, each with its own expiry rules and suspension triggers. It is a legitimate choice for a demo, and a fragile one for anything you care about.
The sensitivity that matters most is storage. Render bills Postgres storage at $0.30/GB-month beyond the included 1 GB, while the flat-rate box includes 40 GB whether you use 1 GB or 39. Walk a plausible growth curve — a side project that accumulates uploads and event history at a few GB a year:
| Database size | Render option A (DB only) | Render option B (always-on) | Flat-rate box |
|---|---|---|---|
| 1 GB (month 1) | ~$7/mo | ~$13–14/mo | ~$6.92/mo |
| 6 GB (month 6) | ~$8.50/mo | ~$14.50–15.50/mo | ~$6.92/mo |
| 11 GB (month 12) | ~$10/mo | ~$16–17/mo | ~$6.92/mo |
The crossover is not dramatic at side-project scale — but the shapes differ. Render's line slopes gently upward with your data, while the box stays flat until you outgrow the whole machine and step to the next size (the 4 vCPU CX33 at ~$10.38). Note the box has its own cliff, just a distant one: at 40 GB of disk you resize or attach a volume, not unlike a meter restarting. The honest difference is where the cliffs sit: Render's first one arrives on day 30, the box's first one arrives when your side project is no longer small.
Which door for which project? If the app is a demo with a known end date, option C (external free database) is rational — just calendar the external tier's own limits so you don't trade one surprise for another. If the app matters but sleeps fine between visits, option A keeps you on one vendor for roughly the price of the box, with backups included. If the app needs to be awake — webhooks, cron-adjacent workloads, a portfolio piece that must load fast for a recruiter — option B is the real Render price, and that is the number to compare against the box: ~$160/year versus ~$83/year, roughly double, with the gap widening as data grows.
The honest cost of leaving
Option D wins the invoice comparison and loses the "who does the work" comparison, so price the work. The migration itself is an afternoon, but it has a deadline: pg_dump your database before day 30, because an expired free database is inaccessible until you upgrade it — the grace period preserves your option to pay, not your ability to read. The checklist after that is short and non-negotiable:
- Restore the dump into a Postgres container with a persistent volume on the new box.
- Point the app at the new connection string and verify under load, not just on the homepage.
- Set up automated backups with off-box copies —
pg_dumpon a cron plus object storage is the minimum viable version of what Render's paid tier did for you. - Put minor-version updates and disk-space monitoring on a recurring reminder. Nobody pages you now; that is the deal.
- Plan for connection pooling once the app outgrows a handful of connections. Render's paid tier offers managed pooling; the free tier never did. Self-hosted, that means a PgBouncer sidecar or app-level pooling before connection churn becomes your first self-inflicted outage.
Ongoing, budget roughly an hour a month of attention for a quiet database: checking backups actually restore, applying Postgres minor updates, watching disk growth. Price your own ops time at anything above zero and the $83/year box narrows against the $84/year option A fast. The real savings in option D are not versus the database line — they are versus option B: the box also absorbs the app, the Redis, the cron jobs, and the second side project, each of which would be another $5–7/month line on a metered platform.
There is one more cost worth naming: irreversibility of habit. Every month your data lives in managed Postgres, your backup/restore/monitoring muscles atrophy a little. Migrating on day 29 under email pressure is how restores get tested for the first time during the actual restore. If you intend to self-host eventually, migrate while the database is small and the stakes are a side project — boring migrations are a skill, and small ones are practice.
Why "no expiry date" changes the calculus
Render's free tier is still one of the last genuinely free-forever compute offers standing — most rivals moved to trial credit or killed free entirely years ago — and the 30-day database clock is best understood as the business model showing through the generosity: compute is cheap to give away, durable state is not. There is nothing dishonest about it. But it reframes what "free tier" means. The question stops being "how much can I build for free" and becomes "when does the meter start, and on which resource."
A platform where the database is a container on hardware you already pay for inverts the question again: from "when does the meter start" to "what does the hardware cost." There is no day 30 because there is no per-resource meter — the CX23 costs $6.92 in month one and $6.92 in month thirteen, whether it holds one database or five. What you give up is the managed part: backups, failover, version upgrades, and the 3 a.m. pager all come back to you. That is a real trade, and anyone telling you otherwise is selling something.
So the practical advice is a calendar, not a vendor. If you deploy anything with a database on Render's free tier today, set a reminder for day 25: dump the database, decide which of the four rows in the table you want to live in, and act while every option is still open. The gotcha is only a gotcha if the 30 days surprise you. Now they won't.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
