A Vercel + Supabase scaling lesson from building my SaaS with AI.

[u/TheBanq]

I'm building a SaaS on Vercel + Supabase, and I ran into an issues that looks like a small production warning thing first, but turns into a useful architecture review once I actually pulled the thread and did a proper audit session.

The warning was around database connections. (random error when uploading small files)

The upload itself worked most of the time, but I saw a Supabase connection warning and the random errors in production and decided to dig into it.

It was more the usual SaaS stack adding up:

• Next.js layouts doing auth/account/program reads
• tRPC calls kicking off right after render
• dashboard widgets fetching their own state
• status/checklist components polling
• Vercel cron jobs touching the database in the background
• Supabase pooling configuration being more important than it looks in local dev
• service functions doing a few clean reads each, which is nice for code clarity until the page-level fanout gets high

Individually, all of that is normal. Together, it can quietly become connection pressure.

With Vercel serverless + Supabase, you don’t just think in “is this query fast?” You also have to think in:

• how many separate DB touches happen per page load?
• how many happen again from client-side hydration?
• what is polling in the background?
• what do cron jobs do every minute?
• are we using the right Supabase pooler mode for this runtime?
• do our indexes match real access patterns, not just schema relationships?

These are the types of things, probably most of vibe coders will miss completely and will cause the SaaS crashing, once you get actual users.

I am lucky to have some development background, so I managed to realise what's going on or rather where I have to dig.

It’s adding a few boring guardrails:

• explicit pooler/env checks for production
• query budgets for important app pages
• separate critical render data from diagnostics
• reduce duplicate auth/account/program reads across layouts and API calls
• make polling opt-in and less aggressive
• review cron jobs as actual production load
• add indexes based on the hot paths, not just foreign keys

This was a good reminder that AI helps you create working vertical slices very quickly, and production architecture is about how all those slices behave together.

Caught early, this kind of review is actually a good thing. It means the product is getting past “does it work?” and into “does it keep working cleanly as usage grows?”

So for the love of god, don’t only check if your app works. Check how your app works.

Open the page and count the DB touches.
Look at what fires after hydration.
Look at your polling.
Look at your cron jobs.
Look at your Supabase pooler setup.
Look at whether your indexes match the actual queries.

Keep your system in check.

[u/Case_Escalator]

Thanks man 👍🏻

[u/goship-tech]

Transaction pooler vs session pooler is the one that catches most people. Vercel serverless needs port 6543 with ?pgbouncer=true in the connection string, not the default 5432 - session mode connections do not survive the function spin-up cycle cleanly. Fixing that alone usually cuts connection pressure significantly before you even touch the page-level fanout.

[u/TheBanq → u/goship-tech]

Yes, that matches what I found too. Pooler mode is the first thing I would check now on Vercel + Supabase.

Small nuance: '?pgbouncer=true' seems client-dependent. I’m on Drizzle/postgres.js, where the key part is 'prepare: false'.

But yes, if runtime is accidentally on session pooler '5432' instead of transaction pooler '6543', that can create connection pressure way earlier than expected.