When your app needs data from a database, it sends a request over the network. That request has to physically travel between two machines — your server and your database.
If they're in the same region (say, both in US East), that trip takes a few milliseconds. If your server is in San Francisco and your database is in Tokyo, every single query has to cross the Pacific Ocean and back. That adds up fast.
There's no engineering trick to fix this — the limit is physics. Nothing travels faster than the speed of light, and even light takes ~50ms to cross the Pacific through a fiber optic cable. You can't optimize your way past the speed of light.
A typical page might make 5–10 database queries to load — the current user, their permissions, the page content, related items, notifications, etc. If each query adds 100ms of network travel, that's an extra full second of waiting — just from distance.
| Setup | Round-trip per query | 10 queries |
|---|---|---|
| Same region | ~1–5ms | ~10–50ms |
| Cross-continent | ~100–200ms | ~1–2 seconds |
Put your server and database next to each other. When you pick a region for your Vercel deployment, choose the same region as your database. That's it.
All major database providers (like Turso, PlanetScale, or Supabase) let you pick a region — because data is inherently tied to a physical location. You can move compute anywhere, but not data.
Globally distributed databases like Cloudflare D1 or Azure Cosmos DB exist, but they're the exception, not the norm — and they come with serious operational complexity that you don't want to deal with as a beginner. So just make sure your server and database regions match.
CDNs solve this for static content — they cache files at locations close to the user around the world. But for server-side compute that talks to a database, it's the opposite problem. You want your compute close to the database, not the user.
?What is a CDN?This is why edge computing platforms like Cloudflare Workers can actually make things worse — by default, your Worker runs at the nearest edge to the user, but it still has to reach your database on every query. A user in London hitting an edge Worker crosses the Atlantic on every database query to US East.
Cloudflare now offers region placement to fix this — you can pin your Worker to run in the same region as your database. This gives you the same co-location benefit as a traditional server, but on Cloudflare's platform.
{ "placement": { "region": "aws:us-east-1" } }