The Long-Term Database Layer with Supabase

If you followed Part 2, you now know Render's free database has a 30-day expiration date baked in. That's a dealbreaker for anything you want to keep working past a month — a portfolio project, a hackathon entry you want to keep demoing, or coursework you'll reference later. This is exactly the gap Supabase fills.

Prerequisites

• A Supabase account.

• A backend service already deployed (from Part 2, or any backend you're running) that needs a database to connect to.

Why Supabase

Supabase is often described as "the open-source Firebase alternative," and that undersells it a bit for our purposes — under the hood, it's a fully managed PostgreSQL database, bundled with authentication, file storage, realtime subscriptions, and auto-generated APIs. For this series, what matters most is one thing: it's a genuinely free database, not a 30-day trial with a delete switch.

Free Tier Limits You Need to Know

Supabase's free tier isn't unlimited, so know the shape of it:

• 500 MB of database storage, plus 1 GB of file storage

• Up to 2 active free projects per account

• 50,000 monthly active users (irrelevant for a class project, but good to know)

The nuance that matters most: free Supabase projects pause after 1 week of inactivity. This sounds similar to Render's limit, but it's fundamentally different — Render deletes your data after 30 days. Supabase just pauses the project. Nothing is lost. You resume it manually from the dashboard, and you're back in business within about 30 seconds. Think of it as the database going to sleep, not dying.

If you have a demo coming up after a quiet week, just remember to log in and hit "Resume" beforehand — or set up a scheduled ping (a simple GitHub Actions cron job hitting your API) to keep it warm automatically.

Connecting Supabase to Your Render Backend

Once your Supabase project is created, grab the PostgreSQL connection string from Project Settings → Database. Drop that into your Render web service's environment variables (typically as DATABASE_URL) in place of Render's own free database connection string. Your backend code doesn't need to change — it's still just talking to a standard Postgres instance, only now that instance survives past the 30-day mark.

The Complete Free Stack

Put it all together and you've got a production-shaped architecture that costs $0/month:

• Vercel → frontend, auto-deployed from GitHub, custom domain attached

• Render → backend API, auto-deployed from GitHub, aware of its 15-minute sleep

• Supabase → persistent database, that "pauses, doesn't delete"

That's a real deployment pipeline — the same shape as production stacks at actual companies, just sized for a student budget of zero.

Final Mentor Tips

• Don't panic if your app feels slow on the first request after a break — that's Render or Supabase waking up, not a bug in your code.

• Keep your .env values out of GitHub; set them directly in the Vercel/Render/Supabase dashboards.

• Once this stack feels natural, that's your "it works everywhere" moment — not just on your machine.

Thanks for following along — see you at the next one.