Choosing an Edge Region: Latency, Data Residency and Cost

Start with two maps, not one. The first is user concentration: pull request counts by country or metro area from your CDN or access logs over a representative month. The second is data location: list every database, object store and third-party API your function calls, and the region each one lives in.

The two maps rarely agree. A media site may draw most readers from Europe while its primary database sits in Virginia, and a B2B tool may have users spread thinly across dozens of countries but a single tenant cluster in Frankfurt. Supabase's documentation makes the trade-off explicit: edge functions execute closest to the user by default, but functions doing bulk database operations, large file processing or complex multi-round-trip queries often perform better pinned to the database region Supabase.

Write the two maps into a short table before you touch a dashboard. A worked example for a fictional store:

Reading this table, Frankfurt is the obvious first candidate: it serves the largest cluster and sits next to the orders database, which is the dependency that multiplies latency. Singapore is a candidate only for catalog reads. That is a placement decision you can defend in review, and it takes an afternoon to assemble.

Never ship a region choice based on a map. Measure. You want two numbers per candidate: the round trip from representative user locations to the edge node, and the round trip from that edge node to your data.

For the first, run a small probe from monitors in each user cluster against an endpoint deployed in each candidate region. For the second, time the actual database call from inside the function. The gap between the two is usually the surprise. Supabase users have documented the pattern: a hello-world function returns similar latency from any region, but a function making a few database calls went from 250ms in us-west to 1.1s in us-east to 2.3s in the Asia region, because every query crossed an ocean GitHub discussion.

Cold starts belong in the same measurement. Serverless functions can pay initialisation latency when an instance is created, and estimates for container-based platforms range from a few hundred milliseconds to a few seconds PayPro Global. Edge runtimes compress that, with one comparison putting serverless cold starts at roughly 50 to 500ms and edge cold starts at 50 to 200ms Netlify. Supabase reported internal medians of about 400ms for a cold first request and about 125ms for warm requests, varying by roughly 100ms across regions GitHub discussion. Treat those as reference points, then measure your own function, because your bundle size and dependencies move the number.

A practical probe loop looks like this:

# Deploy the same function to each candidate region, then sample from each user cluster
for region in eu-central-1 us-east-1 ap-southeast-1; do
  for run in $(seq 1 50); do
    curl -s -o /dev/null -w "%{time_total} $region\n" \
      -H "x-region: $region" "https://your-function.example/?probe=$run"
  done
done | sort -k2,2 -k1,1n

Sort by region, then by time, and read the median rather than the mean. One slow outlier should not move your decision.

Latency finds the fastest region. Compliance removes some of them. Data residency means the data, including in-transit copies, backups, metadata and processing intermediaries, stays inside a jurisdiction's borders, while data sovereignty means the data is governed by the laws of the country where it sits OneSourceCloud. A provider can store data in a US region yet route telemetry through another country, which fails a strict residency requirement OneSourceCloud.

In the United States there is no single federal residency statute; requirements arrive through sector rules and state law. HIPAA's Security Rule does not explicitly require US-only storage, but in practice most business associate agreements specify US-only processing, making US residency a de facto requirement for clinical data OneSourceCloud. Financial institutions face similar scrutiny under the Gramm-Leach-Bliley Act and SEC rules, and federal contractors must meet FedRAMP requirements that keep data within the United States OneSourceCloud. IBM frames the wider problem for edge deployments: regulating where data lives is harder when processing is distributed across many locations, so sovereignty has to be designed into the architecture rather than added later IBM.

Turn this into a short classification before you pick a region:

The constraint row matters most. Supabase's documentation warns that when you pin a function to a region with the region header, requests are not rerouted automatically during an outage, so you should plan a manual failover Supabase. Automatic rerouting is a latency feature and a residency hazard at the same time.

Cost comes last because it depends on the region and the data class you have already chosen. Build a simple model: monthly invocations, average execution duration, memory setting and any per-invocation fee your platform charges. Multiply, then add the data transfer your region choice implies.

Region choice changes cost in three ways. First, some platforms charge differently by region, so the same function costs more in one location than another. Second, cross-region database calls add egress, so a globally routed function that queries a single database region pays for distance on every query. Third, tiered controls matter: a platform that offers only an "Earth" style option routes to the nearest user with no toggle, which is cheap to run but unusable for pinned compliance, as early Supabase users discovered when they needed functions beside their database rather than beside the user GitHub discussion.

A worked comparison for a function invoked 50 million times a month, averaging 5ms of execution:

Option D is the underrated one. It follows Vercel's advice to move functions toward the data when query waterfalls dominate Vercel, and it usually minimizes both egress and the number of regions you must audit. Option C is correct when no single region satisfies all three constraints. Supabase's documentation supports the split explicitly: use the user-nearest default for light, latency-sensitive work and pin to the database region for heavy operations Supabase.

Placement also depends on whether your code runs at all on an edge runtime. Edge runtimes expose web platform APIs such as Fetch, Streams, Web Crypto and URL, and they exclude the filesystem, native modules and most Node core modules Edge Runtime guide. Edge also prohibits dynamic code evaluation, so eval and new Function fail, and bundles carry tight size limits OneUptime.

The practical consequence: a region is only a real candidate if your function can be built for that runtime. Teams routinely discover that a library with native bindings or a database driver that needs raw sockets forces the function back to a regional Node runtime, because those APIs are simply not present in the edge environment OneUptime. Check runtime compatibility before you count a region's latency as available.

Two more constraints worth writing into the plan. Isolates are evicted for resource limits or suspicious behavior, so do not store mutable state in global scope and expect it to persist Cloudflare. And because the network routes by anycast, an IP maps to a pool of machines rather than one host, so the "nearest" node can differ between users in the same country and between requests Stack Overflow. Your measurements should reflect that spread, not a single best-case probe.

After the maps, the measurements, the classification and the cost model, the rule is short. Pick the region closest to your largest user cluster that satisfies every residency obligation for the data the function touches, then confirm that the per-request cost at expected volume fits the budget. If no single region clears all three, split traffic by user location or by data type, and pin each path separately.

Add one guard for the future. Re-run the measurements when a user cluster grows past roughly a fifth of traffic, when a new data store changes the dependency map, or when a regulation changes. Re-evaluate the split when cross-region egress becomes a visible line item.

If the function's main job is calling models rather than moving bytes, the region still matters, because routing every model call through one provider's endpoint can add distance you did not plan for. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible key, which keeps the model-call path consistent across regions and makes the placement math simpler: one egress pattern, one pricing unit, everywhere.