Why is my Next.js App Fast Locally but Slow on Vercel with Supabase?

It’s a tale as old as modern web development: You build a beautiful Next.js application, hook it up to Supabase, and everything feels blazing fast on localhost:3000. But the moment you deploy to Vercel and hit production, your API routes crawl, and your Time to First Byte (TTFB) spikes to 1 or 2 seconds.

You might blame Supabase for being "slow," or Vercel serverless functions for "cold starts." But 9 times out of 10, the culprit is geographic distance—your compute and your database are sitting on opposite sides of the planet.

Here is the non-generic, hard-truth guide on why this happens and how to fix it by co-locating your Vercel deployment region with your Supabase database region.

The Problem: The "Cross-Ocean Database Trip"

When you create a new Vercel project, the default region for Serverless and Edge Functions is usually iad1 (Washington, D.C., USA).

Meanwhile, when you set up your Supabase project, you might have chosen a region closer to your target audience—say, ap-southeast-1 (Singapore) or eu-central-1 (Frankfurt).

Here is what happens when a user hits your Next.js API route:

1. User (in Asia) requests a page.
2. Vercel routes the request to the Serverless Function running in iad1 (USA). (Penalty: ~200ms latency)
3. The Serverless Function executes and sends a SQL query/PostgREST request to Supabase in Singapore. (Penalty: ~250ms latency)
4. Supabase processes the query and sends the data back to Vercel in the USA. (Penalty: ~250ms latency)
5. Vercel renders the response and sends it back to the user in Asia. (Penalty: ~200ms latency)

If your API route makes just two sequential database calls (e.g., fetch the user profile, then fetch their posts), that cross-ocean latency multiplies. Your user is now staring at a blank screen for nearly 2 seconds.

Why didn't you notice this locally? Because during local development, you are the single user, and you aren't doing complex sequential data fetching that blocks rendering. Or perhaps you were running Supabase locally via Docker.

The Solution: Region Co-location

To fix high TTFB and reduce latency, you must co-locate your Vercel Serverless/Edge functions with your Supabase database. They need to live in the same AWS/cloud data center, or at least the exact same geographic region.

Step 1: Identify your Supabase Region

Go to your Supabase Dashboard -> Project Settings -> General. Look for the Region setting. Let's assume it is ap-southeast-1 (Singapore).

Step 2: Update your Vercel Region

You need to change where Vercel executes your functions to match Supabase.

1. Go to your Vercel Dashboard -> Project Settings -> Functions.
2. Under Function Region, change the default from iad1 (Washington, D.C.) to sin1 (Singapore).
3. Save the settings and trigger a new deployment. Existing deployments will not switch regions automatically.

Pro tip: Vercel maps their regions directly to AWS regions in most cases. iad1 is AWS us-east-1. sin1 is AWS ap-southeast-1. Matching them exactly gives you near-zero latency between your Next.js backend and your PostgreSQL database.

What if my audience is global?

If your users are scattered worldwide, simply moving the Vercel function to Singapore might fix the database latency, but users in New York will now face slow function execution times.

Here is the advanced playbook for global audiences:

1. Edge Functions + Edge Database / Read Replicas: Vercel Edge functions can run anywhere in the world. If you use them, you'll also need Supabase Read Replicas (available on higher tiers) scattered globally. The Edge function queries the closest replica.
2. Aggressive Caching: Stick to Serverless functions in one region (matching your primary DB), but aggressively use Next.js Data Cache (fetch with next: { revalidate }) or Incremental Static Regeneration (ISR). Let the CDN serve the global users instantly, and only pay the latency penalty when revalidating the cache.
3. Optimistic UI: For mutations (inserts/updates), use Optimistic UI in your React frontend. Update the UI instantly while the Vercel-to-Supabase request happens in the background.

Stop Blaming the Tools

Before you rip out Supabase or migrate away from Vercel Serverless functions because they are "slow," check your deployment regions. Co-locating Vercel and Supabase is the single most impactful performance tuning you can do for a full-stack Next.js application.