You're being asked whether the product should run in more than one region, probably because a customer asked about data residency or because users far from your servers say it feels slow. Before you touch infrastructure, write down which of those two problems you have and for which customer segment, because the fix for each is different and neither usually needs full multi-region.
This guide covers multi region SaaS deployment for a typical B2B product on Postgres and a Vercel-style host. It separates what you can verify (limits, defaults, regulations) from what is a judgment call, and it ends with the smallest step that closes a real gap. Facts below were checked against the cited vendor and regulator pages on 30 September 2026.
Does your SaaS need multiple regions at all?
Most B2B SaaS products need multiple regions only when a measured latency problem for paying users, a written data-residency requirement, or a recovery-time commitment can't be met from one region.
Treat those as three separate triggers:
- A latency problem you measured. Use real-user timings from the affected geography, not synthetic checks run from your own region. The threshold is yours to set; I'd suggest agreeing one with the team before you start, since no public number applies to every product.
- A residency clause in writing. A signed data processing agreement or contract term that names where data must live is a business constraint. A sales call saying "our data is in the EU" is not.
- A recovery-time commitment. If a contract promises recovery after a regional outage, a single-region deployment can't meet it. That is a disaster-recovery question before it's a latency one.
If none applies, stay single-region: tune queries, add connection pooling, and consider serverless or edge execution where the workload fits. The SaaS MVP stack already serves static assets from a global CDN, so the first-screen experience is usually fast everywhere before you add a second region.
How much does a second region cost?
I can't give you a trustworthy percentage, and you should be suspicious of any blog that does. What the vendors document is structural. AWS describes multi-site active/active as "the most complex and costly approach to disaster recovery" in its disaster recovery whitepaper, and it notes that warm standby is "a more economical and operationally less complex" alternative if you don't want both regions serving traffic. AWS's data transfer cost overview adds that inter-region transfer is charged and that the rate depends on the source and destination regions. Replication, cache sync and session traffic all cross that boundary, so model your own volumes against the current price list before committing.
How do read replicas fit a multi region Postgres setup?
A read replica copies your primary database asynchronously into another region, so nearby users read locally while every write still goes to the primary, at the price of replication lag.
For dashboards, list views and reports, which dominate many B2B products, that is often the cheapest step that changes perceived speed. Supabase's read replica documentation states that replication is asynchronous so transactions on the primary aren't blocked, and that there's a delay between an update on the primary and the replica receiving it. It offers three ways to route reads: dedicated endpoints, dedicated connection pools, and an API load balancer that geo-routes GET requests for the Data API to the closest database.
What do replicas cost and where do they live?
Per Supabase's billing page for replicas, compute is charged hourly at the same size as the primary, the replica disk is 1.25 times the primary disk to hold WAL archives, and replicas aren't covered by the Spend Cap. This suggests each replica adds about one more primary's worth of compute cost, so budget for that before you add regions. Supabase's regions page lists Frankfurt (eu-central-1) and London (eu-west-2) among its specific regions.
What about stale reads?
Because replication is asynchronous, a user who saves a record and immediately opens a list served from a replica may not see it yet. The documentation describes the delay but promises no read-your-writes guarantee. Route the request right after a write to the primary, or show the new record optimistically, and test those flows before shipping. Nothing in this guide gives you a lag figure: measure yours.
Where does your compute run on Vercel, and how do you move it?
Vercel serves static content from 126 points of presence, but Functions run in Washington, D.C. (iad1) by default for new projects until you choose other regions.
Vercel's regions page lists 126 points of presence in 94 cities and 19 compute-capable regions, including Frankfurt (fra1), Dublin (dub1), London (lhr1) and Paris (cdg1). The function region documentation says the default is iad1 for all new projects and recommends placing functions near the data source. You can set regions project-wide in vercel.json, or override them per function:
{
"regions": ["iad1"],
"functions": {
"api/eu-data.js": { "regions": ["fra1"] }
}
}
Plan limits matter here: the same page lists a single region on Hobby, five on Pro, and all regions on Enterprise, and says deployments requesting more than the plan allows fail before the build step. Automatic function failover regions are an Enterprise feature.
One correction to older advice: the Next.js preferredRegion route segment option is marked deprecated in the current Next.js docs, and so is the edge runtime value. Configure regions through Vercel's project or per-function settings instead.
Is the edge runtime faster than a single-region function?
In one benchmark, yes, with caveats. OpenStatus measured a Next.js app across six global regions on 14 March 2024: 106 ms P50 for edge functions, 246 ms for warm serverless and 859 ms for cold serverless, where the serverless functions were deployed in a single region (iad1). That is an old test of a specific setup, and its authors measured routing differences rather than your workload. Use it as a reason to run your own measurement, not as a promise. The Next.js and Vercel Postgres stack page covers the basic setup of that pairing.
The practical rule follows from Vercel's own advice: put the function in the same region as the database it queries. A function in Frankfurt reading a primary in Virginia adds a cross-Atlantic hop to every query, so pair a regional function with a regional replica for reads only.
When does compliance force region-pinned tenants or active-active?
GDPR doesn't forbid storing personal data outside the EU, but Chapter V restricts how it may be transferred, so an enterprise contract can turn a residency preference into a hard requirement.
Article 44 allows a transfer to a third country only if the Chapter's conditions are met, and Article 83(5) puts infringements of the transfer rules (Articles 44 to 49) in the tier of fines up to 20 million euros or 4% of worldwide annual turnover, whichever is higher. The scale is real: Ireland's Data Protection Commission fined Meta Ireland 1.2 billion euros on 12 May 2023 for infringing Article 46(1) by continuing transfers to the US without appropriate safeguards. That's an exceptional case for a very large company, not a startup benchmark. It does show why some buyers ask vendors for a written answer on where data lives. This isn't legal advice; have counsel read the clause.
What are region-pinned tenants?
Region-pinned tenants give each customer one permanent home region, so their data lives in a single database cluster there. AWS's disaster recovery whitepaper describes this family as a "write partitioned" strategy, where writes go to a specific region based on a partition key such as a user ID, which avoids write conflicts. The routing layer looks up the tenant's region (a cached lookup, not a per-request query) and forwards the request. That sidesteps conflict resolution for application data, at a cost: provisioning creates infrastructure instead of a row, and offboarding needs a teardown path.
Tenant boundaries matter whether or not you add regions. Callidus OS, the UK aesthetic-clinic SaaS built on React, Firebase and Stripe Connect, keeps each clinic's data under tenants/{tenantId} paths with Firestore rules and role claims in the JWT. Its case study doesn't describe multi-region hosting, so this is an example of tenant isolation, not of residency. The multi-tenant architecture guide covers the isolation side.
Which step should you build first?
Match the step to the trigger you measured:
| Trigger | Smallest step that addresses it |
|---|---|
| Users in one far region report slow reads | Read replica in that region, function region moved next to it |
| Contract requires data to stay in a region | Region-pinned tenants with a cluster in that region |
| Contract requires recovery after a regional outage | Warm standby or pilot light in a second region (AWS DR strategies) |
| Low-latency writes for users on several continents | Active-active, only after the business case is verified |
For the warm standby row, AWS states that Aurora global database can promote a secondary region "in less than one minute", which is specific to that AWS service and not a general property of multi-region designs.
Your next step: pick one customer segment, collect real-user p95 timings from their location this week, and write down the contract clause or latency number that would justify a second region. If you can't name either, which customer is asking for it?