I was setting up Claude connectors for my Supabase project — checking permissions, tightening auth scopes — when I noticed something.
Region: South Asia (Mumbai)
Wait. I'm in Tokyo. All my beta testers are in Japan.
I was sure I had picked Tokyo when I created this project. But the dropdown said otherwise. Probably got pulled toward India because I had another India-related project on my mind at the time. One wrong click, months ago, that I never looked at again.
And it explained everything.
The Slow First Load That Wouldn't Go Away
For weeks, my app's cold start had been bugging me. Not enough to stop feature development — I was building in parallel across multiple products — but enough to notice every single time I opened the app.
I'd already tried the right things:
- Optimistic UI to decouple data fetching from rendering
- Skeleton screens to improve perceived load time
These helped for navigating between pages. But that first load — opening the app, hitting login — always felt sluggish. I assumed it was a Next.js SSR issue or a Supabase query that needed optimization.
It wasn't. The database was just in the wrong country.
The Migration Tool That Wouldn't Migrate
No problem, I thought. Supabase has a project migration tool. I'll just move it to Tokyo.
Found the "Restore to new project" button in the dashboard. Me and my AI pair programmer literally celebrated.
Clicked it. Read the modal:
"Project region will stay the same: ap-south-1"
The one tool designed for this exact situation... only works within the same region.
Going the Hard Way
So I went manual.
pg_dump → GitHub Actions → new Tokyo project.
First wall: pg_dump version 16 can't dump a Postgres 17 database. No useful error message. Just a silent failure in CI. Had to manually install postgresql-client-17 in the workflow.
Data migrated. Done?
Not even close. The migration docs had warned me — I just didn't appreciate what "manual reconfiguration" actually meant:
- Google OAuth redirect URLs → all pointing to the old project
- Every Vercel environment variable → old project URL and keys
- Supabase anon key, secret key, project URL in
.env→ all old
I was basically rewiring the entire authentication system by hand.
And while I was knee-deep in this, Vercel builds started failing from a completely unrelated bug (Date.now() called during render). Two simultaneous failures. Your brain merges them into one impossible problem.
Was It Worth It?
I measured latency before and after. Here are the honest numbers:
Median latency: nearly identical. ~40ms from both regions. Supabase's CDN does an impressive job absorbing the geographic difference for cached requests.
But the cold start — that first request when your app wakes up?
367ms → 64ms.
That's 82% faster. And that's the moment your users actually feel. The login screen. The first dashboard load. The moment they decide if your app is "fast" or "slow."
All those optimistic UI improvements I'd built? They were masking a structural problem. The foundation was off.
Three Things I'd Tell Anyone Starting a Supabase Project
- Region selection is a one-way door. Pick the region closest to your first users — not your future ones, not the project that's on your mind that day.
- Supabase's built-in migration = same region only. Cross-region means
pg_dump, manual auth rewiring, and a full env var rebuild. Budget a day, not an hour. - Measure your latency before you migrate. Once you switch, that "before" data is gone forever.
I'm building multiple products right now — a structural consulting SaaS, a management dashboard for a wellness business, and some things I can't talk about yet.
Making mistakes along the way and sharing all of it here. Follow @kazbuildsstaff if you want real build-in-public, not the highlight reel.
Top comments (0)