Cross-Zone Databases Are Here: One Cluster, Three Zones, Private Peering
Single-zone high availability is wonderful right up until the zone itself is the thing that breaks. A blown rack, a batched datacenter maintenance window, a regional routing incident, and every replica you so carefully provisioned next to your primary goes dark at the exact same moment. Today that stops being your problem to solve by hand. FoundryDB v0.8.0 ships cross-zone clusters: one managed database, spread across three zones, privately peered, with streaming replication that stays on the cloud backbone and never crosses the public internet.
This is the database property you always wanted and never wanted to build yourself. You ask for three zones, and you get a primary in one, replicas in the other two, a private peering mesh wiring them together, and two DNS records that already point at the right nodes. No second cluster to babysit. No VPN to watch. No 3am page because a replication slot filled up while you were asleep.
What you can build now
Picture the failure you have been quietly dreading: an entire zone drops off the map. With a single-zone cluster, your primary and all of its replicas were in that zone together, so they go down together. With a cross-zone cluster on FoundryDB, two of your three nodes are sitting in different zones entirely, on the same low-latency backbone, already streaming. The incident that used to mean downtime now means you promote a replica that has every byte the primary had.
That unlocks a class of deployment that previously meant running two clusters and gluing them together yourself: regulated workloads that must survive a facility going offline, write paths that cannot afford correlated noisy-neighbour degradation, systems where a scheduled hypervisor maintenance window across one zone should be a non-event. Cross-zone is now a checkbox at create time, not a weekend project that turns into a quarter.
How it works
When you create a service with three zones in one peering region and ask for three nodes, the controller does the heavy lifting in order:
- Provisions one private SDN network per zone, each with its own subnet.
- Attaches every zone network to a shared router and builds a bidirectional peering mesh, so every network learns routes to every other.
- Allocates one VM per zone at the tier and storage size you asked for.
- Installs the engine from a prebuilt zone-local template, configures TLS, and starts the primary in your first zone.
- Initialises streaming replication from the primary to the other two nodes over the peered private network. Replication traffic never traverses the public internet.
- Publishes two DNS records: a primary record that always points at the current writer, and a read-only record that round-robins across the two cross-zone replicas.
The peered private network is the part that makes the whole thing realistic. Cross-zone traffic in European peering regions stays on the provider backbone, which gives predictable latency floors and no egress-metered hops. That is what makes replication between Stockholm and Helsinki feel like it is happening down the hall.
The numbers, measured
These are not aspirations. They come from a validated PostgreSQL 17 three-zone cluster on staging, tier-4 nodes, 200 GB maxiops storage.
| Metric | Value |
|---|---|
| Time to Running | approximately 14 minutes |
| Cross-zone replay lag after 50,000 row insert | under 1 second |
| LSN drift between primary and both replicas at steady state | 0 bytes |
| Replication path | peered private SDN, no public internet |
The 50,000-row test writes on the primary and polls replay position on both replicas. By the time the insert returns, both replicas have already reached the identical LSN as the primary. Zero drift at steady state. That is exactly the picture you want: replication is not your bottleneck, and your failover target is not running behind.
A word of honesty on provisioning time. Fourteen minutes is longer than our roughly five-minute single-zone baseline, and we are not going to pretend otherwise. Most of the gap is sequential network setup (three SDN networks, the peering mesh, router attachments) before the first VM even boots. We have a clear path to bring this down by parallelising that work, and it is coming.
What you ask for, and what it costs
You request the cluster with a single payload. Three zones in the same peering region, three nodes, the storage and tier you want:
{
"name": "orders-prod",
"database_type": "postgresql",
"version": "17",
"plan_name": "tier-4",
"zones": ["se-sto1", "fi-hel1", "de-fra1"],
"node_count": 3,
"storage_size_gb": 200,
"storage_tier": "maxiops"
}
The zones array and the single-zone zone parameter are mutually exclusive. If you pass zones, your node count must equal the length of the array, and every zone must live in the same peering region. Today that means a European region (se-sto1, fi-hel1, de-fra1, uk-lon1, es-mad1, pl-waw1, no-svg1, nl-ams1) or a US region (us-chi1, us-nyc1, us-sjo1).
On pricing, we kept it honest. Cross-zone PostgreSQL is 2.5x the equivalent single-zone cluster, which reflects the real cost of three VMs plus peered networking and nothing more. For the same three-zone topology, MongoDB Atlas charges 3x. We did not price in the assumption that you would not shop around.
What comes next
PostgreSQL 17 is the first validated engine, and it is genuinely production-ready today. MySQL, MongoDB, Valkey, Kafka, and OpenSearch are next in line. Kafka is a particularly satisfying fit, because it already wants an odd number of brokers across fault domains, and three zones map cleanly onto its quorum model.
We are also building automatic cross-zone failover. Right now, if the primary zone becomes unreachable, you promote a replica through the API. The next release will do it for you, with configurable health thresholds so you decide exactly how aggressive promotion should be. That is the roadmap, stated plainly: manual promotion works today, automatic promotion is the next chapter.
The bottom line is simple. A whole zone can go dark and your database keeps its data, on a private backbone, in Europe, next to everything else you run here.
Provision your first three-zone cluster from the REST API, the SDKs, or your AI assistant through the MCP server. Already running single-zone on FoundryDB? The upgrade path is a cluster-to-cluster logical replication migration, and we are happy to walk you through it. Go build something that survives the bad day.