Managed databases, and the free-tier expiration gotcha
Railway's own domain covered persistent volumes as the mechanism that makes a database survive a container's disposable lifecycle. Render's managed databases solve the same underlying problem — and introduce a real, specific, free-tier-only gotcha that's caught a genuinely large number of first-time users by surprise.
Intermediate
2 min read
Render's managed Postgres and Redis, briefly
Render provisions and operates Postgres and Redis as managed services, the same basic value proposition this curriculum's other platform domains already established — automated backups, point-in-time recovery (restoring to any specific moment within a retention window, not just the latest backup snapshot), and no manual server patching or version upgrades for a team to handle themselves.
The free-tier gotcha: a database that expires, not just a service that sleeps
Render free PostgreSQL: expires 30 days after creation,
PERMANENTLY, with no automatic renewal
This is the single most commonly-hit surprise for anyone trying Render's free tier for a real side project: a free Postgres database is deleted entirely after 30 days, with no warning banner that's easy to miss and no automatic way to extend it — the data is genuinely gone, not just paused or suspended. This is a materially different, more severe gotcha than the free web service spin-down behavior (lesson 6 covers that one directly) — a spun-down service wakes back up on the next request; an expired free database simply doesn't exist anymore.
Why this specific gotcha matters more than it might seem
A team prototyping on the free tier, genuinely planning to upgrade to a paid plan "once it's ready for real users," can lose everything if that 30-day window passes unnoticed during active early development — exactly the kind of gap between "technically documented somewhere" and "actually noticed before it mattered" this curriculum's own Vercel domain described for its own, different real incident. The practical defense is simple and concrete: either upgrade to a paid database plan before the 30-day mark for anything with data worth keeping, or treat a free-tier database explicitly as genuinely disposable, ephemeral test data from the start — never as a real project's source of truth, even temporarily.
Backups on paid plans: what "automated" actually covers
Point-in-time recovery window: up to 7 days (varies by plan)
A paid database plan's automated backups let you restore to any point within a configured retention window — this protects against the accidental-deletion and corruption risks Railway's own domain named directly (a persistent volume alone doesn't protect against those), but it's still bounded by the retention window itself: something that needs restoring from 3 weeks ago, on a plan with a 7-day window, is unrecoverable through backups alone regardless of plan tier.