The schoolroom story of multi-region SaaS goes through a globally distributed database with strong consistency, automatic failover, and transparent routing. The cost of that story in 2026 is six figures of monthly database spend, ongoing operational tax, and a non-trivial probability that the system is slower than a single-region setup for the workload that actually runs in production. The honest pattern for almost every SaaS at under a few thousand customers is per-region single-master databases with explicit tenant-to-region routing and asynchronous replication for the cross-region surface that genuinely needs it.
This post covers what regional actually means in practice, the per-region database pattern, the tenant-routing layer, the cross-region replication discipline, the failover story that comes with this architecture, and the threshold at which graduating to a globally distributed database earns its weight.
What regional actually means
The first question to answer before any architecture decision is what business problem multi-region is supposed to solve. The three honest cases are: data residency requirements where the customer contract or local law requires data to stay in a specific jurisdiction; latency requirements where the round trip to a single region is large enough to matter for the workload; and disaster recovery requirements where the business cannot tolerate the outage probability of single-region operation. These cases have different solutions and the conflation produces architectures that solve none of them well.
Data residency is satisfied by per-region databases with no cross-region replication for residency-scoped tenants. Latency is satisfied by per-region read replicas or by per-region full deployments depending on the read-vs-write ratio. Disaster recovery is satisfied by cross-region backups plus a documented runbook with realistic recovery-time objectives. Each of these is a different system; none requires a globally distributed database for almost any SaaS at startup or growth-stage scale.
Per-region single-master databases
The pattern that survives is a single-master PostgreSQL or SQLite per region, with each tenant's data living entirely in one region. The region assignment happens at signup, defaults to the closest region, and is sticky for the lifetime of the tenant. The tenant ID carries the region as a prefix or as a separate column in the routing table, and the application looks up the region before any database operation.
The benefits compound: each region operates independently with its own backup, monitoring, and failure domain; the database operations are local with single-millisecond latency rather than cross-region tens-of-milliseconds; the failure of one region is contained and does not cascade to other regions; and the operational story is the same single-region story repeated N times rather than a fundamentally different distributed-systems story.
The cost is that some operations require cross-region coordination: tenant-to-tenant communication where the tenants live in different regions; analytics queries that aggregate across regions; and the rare case where a tenant needs to migrate from one region to another. Each of these has an honest pattern that works without a globally distributed database.
The tenant-routing layer
The application layer needs a way to route requests to the correct region. The simplest implementation is a small replicated metadata table that maps tenant ID to region, served from a fast key-value store with cross-region replication. The metadata table is small — kilobytes per thousand tenants — and the read pattern is high-volume but extremely cache-friendly. Cross-region replication of this single small table is the actual distributed-systems problem worth solving.
The routing happens at the edge: a small Lambda, Cloudflare Worker, or front-end proxy reads the tenant ID from the request, looks up the region, and routes the request to the regional API endpoint. The latency cost is one extra DNS resolution and one extra hop; the benefit is that the application code can pretend it is single-region.
For the four Anethoth products — DocuMint, CronPing, FlagBit, and WebhookVault — the routing layer is currently the trivial single-region case, but the architecture is set up to add the routing layer when the latency or residency case earns it.
Cross-region replication discipline
Some data has to cross regions: user authentication where the user might log in from anywhere; team membership where teams might span regions; billing data where the financial system needs a single source of truth. The discipline is to identify this surface explicitly, keep it small, and replicate it asynchronously with eventual consistency.
The pattern is a small global database — the metadata table mentioned above, plus a few additional tables for users and teams — that lives in a single region and is replicated asynchronously to other regions for read availability. Write operations against this database are accepted only in the home region; cross-region writes are queued and forwarded. The latency cost for the rare write is acceptable because writes to this surface are infrequent compared to reads.
The key discipline is keeping the global surface small. Every table that crosses regions is a table whose schema changes have to be coordinated across regions, whose backup story is more complex, and whose failure modes are harder to reason about. The default answer to "should this be in the global database" is no, and the burden of proof is on the person arguing for inclusion.
Failover and disaster recovery
The failover story for per-region single-master databases is honest about its limits. If a region fails, the tenants in that region are unavailable until the region recovers. The recovery-time objective is set by the database backup and restore time, typically minutes to hours depending on data volume and provider. The recovery-point objective is set by the backup frequency, typically minutes for transaction-log streaming or hours for snapshot-only backups.
The honest accounting is that this story is worse than the marketing story for globally distributed databases, but it is much better than the marketing story would suggest. The probability of a region-level failure is small for the major cloud providers, the recovery time is acceptable for most SaaS, and the operational cost saved over years pays for the occasional incident multiple times over.
The escape hatch for tenants who genuinely cannot tolerate region-level downtime is a manual or automated tenant migration to a different region, which becomes practical once the per-tenant data is well-isolated. The migration is a database export, a database import, and a routing-table update, executed in minutes for typical tenant sizes.
When to graduate
The signals that suggest graduating to a globally distributed database are: the cross-region surface has grown to the point where the asynchronous replication pattern is producing noticeable user-facing inconsistency; the failover story is no longer acceptable to the business; the operational cost of running per-region databases has exceeded the cost of a managed distributed database. None of these signals appear at small or medium scale, and the rule of thumb is that the per-region pattern is the right answer for the first several years of any SaaS.
The deeper observation is that multi-region architecture is mostly a marketing story for SaaS at startup or growth-stage scale. The customers who care about it are large enterprises whose contracts mention specific regions; the customers who do not care about it are most of everyone else. The right answer for almost every SaaS is to run single-region until the contract or the latency forces a region split, and then to do the region split with the simplest pattern that meets the actual requirement. The pattern described here scales to most SaaS sizes that any indie or small team will ever reach, and the engineering simplicity of single-master databases is worth defending.