Multi-region deployment is one of those decisions that looks like an architecture choice but is actually a business question wearing a hoodie.
Most products I see start here: first serious enterprise inquiry, procurement form has a "data residency" checkbox, someone types "multi-region deployment" into a search bar for the first time at 10pm. That's fine. The instinct is right. The timing is usually wrong.
This post covers when to do it, what it actually costs, and the practical patterns — read replicas, region-pinned tenants, Vercel + Supabase configuration — that get 80% of the benefit without Active-Active complexity.
Does Your SaaS Actually Need Multiple Regions?
Most B2B SaaS products don't need multi-region until they have paying users in regions with measurable latency problems or a regulatory constraint that requires data to stay in a specific jurisdiction. That's the threshold. Everything else is premature.
Three signals worth acting on:
-
P95 API latency above 300ms for a specific user segment. Not a vanity metric. Amazon's internal research, documented across multiple performance studies, found that 100ms of added latency reduces sales by 1%. At 300ms you've conceded three. Measure with real requests from affected users — not synthetic monitoring running from US-based nodes. You've felt this. Page loads. You wait. Users are less patient than you.
-
A procurement document requiring data residency commitments in writing. Not "our data is in the EU" spoken on a call — a signed DPA addendum. UK public sector tenders increasingly require a UK-only data path. EU enterprise contracts often include explicit regional clauses. If this is blocking a contract, it's a business constraint, not a latency optimization.
-
An SLA requiring sub-hour RTO. A single-region deployment fails that if the region goes offline. A properly configured Active-Passive architecture — warm standby, writes in primary only — achieves RTO of minutes depending on automation.
If none of these describe your product: stay single-region. Optimize queries, add connection pooling, deploy edge functions where the workload fits. That's faster to ship and orders of magnitude cheaper to operate.
What Does Multi-Region Actually Cost?
The cost ceiling is what kills this pattern for most early B2B SaaS.
Active-Active — where both regions accept live writes — costs 2x or more of single-region infrastructure, and Active-Passive costs roughly 1.5x. Neither figure includes engineering hours to run quarterly failover drills, maintain cross-region observability, and debug the consistency edge cases that will eventually surface.
Rough order of magnitude: if you're at $500/month on infrastructure today, plan for $750–$1,000/month minimum for a properly-run Active-Passive setup. At $5,000/month, expect $7,500–$10,000+. The surprise line item: cross-region egress. On AWS, data crossing region boundaries costs $0.02/GB. Replication logs, cache invalidation, session sync — at scale this adds real money to a bill you weren't expecting.
Wednesday at 11pm, Stripe webhook started 500-ing. Manageable in single-region. In Active-Active, a webhook retry could hit either region and double-write if your idempotency layer isn't airtight across regions. Same failure. Twice the blast radius.
For a SaaS under $50K ARR with users mostly in one geography: this is architecture for a company you don't have yet. Solve it when revenue makes the infrastructure cost proportional to what you're protecting.
How Do Read Replicas Fix Latency Without the Full Cost?
Read replicas get you most of the multi-region latency benefit for read-heavy workloads at a fraction of Active-Active complexity.
One primary database in your main region. Read replicas in secondary regions. EU users read from the EU replica. US users read from US-East. Every write still goes to the primary. Replica lag for standard Postgres is under one second for most configurations. For a product where dashboards, list views, and reports make up the bulk of traffic — which describes most B2B SaaS products — this often drops EU latency from 200ms to under 50ms.
Supabase runs in 16 AWS regions and supports read replicas as a Pro add-on. Each replica is an independent Supabase project in the target region, billed separately for compute. Configure your application to send read queries to the region-nearest replica and write queries to the primary. The Next.js + Vercel Postgres integration supports this at the connection string level — two environment variables, no application logic changes.
The sharp edge no one mentions in the documentation: replica lag is real. A user who creates a record and immediately navigates to a list view may see stale data on a replica that's 300ms behind the primary. Not a bug. Expected behavior. Test this against your actual flows before shipping.
What Does Vercel Actually Give You for Global Latency?
Vercel's CDN operates 126 Points of Presence across 94 cities, backed by 20 compute-capable regions where serverless functions run. That's globally distributed caching. Not multi-region compute by default.
What most teams miss: Vercel Functions default to iad1 — Washington DC, US-East-1. A user in Frankfurt hits your API and the request travels to Washington DC and back. Around 180ms of network before a line of your code executes. Static assets are fast everywhere. Your API is slow in Europe until you change the config.
Actually — that slightly overstates it. Some of that 180ms is absorbed by Vercel's private network between PoP and region. The observable impact depends on your specific request pattern. The point stands: default config is US-only compute, and you need to opt out of it for EU users.
Two configurations that matter:
Edge Functions execute at the nearest PoP. A 2024 OpenStatus benchmark measured Edge at 106ms P50 globally vs. Serverless warm at 246ms and cold start at 859ms — 9x faster on cold starts. The constraint: Edge runs in a limited runtime. No native modules. If your handler reads from a database and returns JSON, it probably fits. If it imports Prisma with N+1 queries or runs longer computation, it doesn't.
Region pinning: set preferredRegion = 'fra1' on EU-targeted routes, paired with a Supabase eu-central-1 read replica. EU users get Frankfurt compute reading from a Frankfurt database. No Active-Active. No conflict resolution. Two environment variables and a read replica.
When Does Compliance Force the Architecture?
Data residency requirements change the conversation from "optimization" to "requirement."
GDPR doesn't strictly require data to remain within EU borders — the requirement is adequate protection, not physical location. But EU infrastructure eliminates the data-transfer legal question entirely, and enterprise procurement teams don't want to review your legal analysis. They want a checkbox.
The penalties are public record. Meta received a €1.2 billion GDPR fine in 2023 for unlawful EU-US data transfers. TikTok absorbed €530 million in 2025 for failure to protect EEA user data from unauthorized access in China. GDPR violations scale to 4% of global revenue. These aren't early-stage startup risks — but they explain what your EU enterprise prospects have in the back of their minds when they tick that residency checkbox.
The pattern that works: split architecture into what stays regional and what can route globally. High-volume sensitive content stays in the customer's region: your application data, user records, files. Low-volume control-plane operations can cross borders — authentication tokens, Stripe webhooks, analytics telemetry. OpenAI operates this model since February 2025. Slack since December 2019. The content plane is regional; the control plane is global.
Region-Pinned Tenants: The B2B Compliance Pattern
Region-pinned tenants satisfy enterprise data residency requirements without the conflict-resolution overhead of Active-Active.
Each tenant is assigned to a database cluster in a specific region at provisioning time. A UK customer goes to eu-west-2 (London). A US customer goes to us-east-1. That assignment is permanent and stored in a global routing table — a cache lookup at the edge, not a per-request database query. Every request for that tenant routes to their assigned region's cluster. Same codebase. Different data home per tenant.
This sidesteps conflict resolution because each tenant's data has exactly one home. The routing layer resolves the tenant's region and forwards to the right cluster. No cross-region replication of application data. No conflict resolution needed.
Callidus OS — the UK aesthetic clinic platform I built on React + Firebase — uses per-tenant Firestore isolation with security rules that enforce hard boundaries at the tenant level. Not multi-region, but the same principle: strict data boundaries per customer are what make a compliance posture certifiable. Procurement teams increasingly can tell the difference between "tenant isolation enforced in application code" and "tenant isolation enforced at the database boundary."
The operational cost is real. New tenant provisioning spins up a database cluster, not just a row in a table. Churn handling needs a teardown path. Cross-region visibility requires aggregated monitoring. Solvable problems. Not free ones.
Should You Build Multi-Region Right Now?
For most products at most stages: no.
The SaaS MVP stack — Next.js on Vercel, Supabase for the database — is already global in the CDN layer. Static content is fast everywhere. The optimization ladder before full multi-region:
| Situation | What to build |
|---|---|
| EU users reporting slow load times | Supabase EU read replica + Vercel preferredRegion on API routes |
| Enterprise prospect requires documented residency | Region-pinned tenants with EU cluster |
| SLA demands sub-hour RTO | Active-Passive: add a warm standby region |
| Global users needing low-latency writes | Active-Active (expensive — verify the business case first) |
The read replica step costs roughly $50–$100/month extra and a day of configuration work. Region-pinned tenants take a sprint. Full Active-Active takes a quarter and a budget conversation.
Build the increment that closes the next deal. Then re-evaluate.