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.

Heads Up: Your Direct Connection String Might Silently Fail

Here's something that trips up a lot of people, and it's recent enough that older tutorials won't mention it: Supabase's default Direct connection string (db.[project-ref].supabase.co) now resolves over IPv6 only.

That's fine if your network fully supports IPv6. But a lot of home routers, campus networks, and ISPs still don't — and when that's the case, a direct connection attempt with a tool like psql doesn't throw a clean error. It just hangs, or times out, or fails silently. If you copy the Direct connection string straight from the dashboard and it "just doesn't connect" for no obvious reason, this is almost always why.

The fix is Supabase's Connection Pooler, which routes through pooler.supabase.com and acts as an IPv4 bridge. Here's how to get the right string:

1. From your Supabase Project Overview, click Connect.

2. Select the Direct (Connection string) option.

3. Under Connection Method, choose either Transaction pooler (port 6543) or Session pooler (port 5432) — which one depends on your app's architecture (transaction mode for short-lived/serverless-style connections, session mode for persistent ones). Both generate an IPv4-compatible connection string.

4. One thing that confuses people here: the dashboard shows a warning on the Transaction pooler saying it "uses IPv6 by default." Don't let that stop you — that warning refers to the pooler's own upstream routing, not the URI it hands you. The connection string you actually copy still routes through the pooler.supabase.com domain and connects fine over IPv4 from a local terminal.

5. Copy that URI and use it wherever you were about to use the direct one — psql, your .env file, or your Render environment variables.

Bottom line: default to the pooler connection string, not the direct one, unless you specifically know your network supports IPv6. It'll save you a confusing debugging session.

Connecting Supabase to Your Render Backend

Once your Supabase project is created, grab the pooler connection string covered above (not the Direct one) from Project Settings → Database → Connect. 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 and connects reliably regardless of your local network's IPv6 support.

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.

• Default to the pooler connection string over the direct one — it saves you from IPv6 headaches on networks that don't fully support it.

• 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.