Concept Library
Multi-Region Data Architectures
Patterns for distributing data across regions to satisfy residency laws, latency requirements, and disaster-recovery commitments — without losing analytical coherence.
What it is
A multi-region architecture decides three things: where data physically lives, how regions communicate, and how analytics see across them. The drivers are usually some combination of:
- Data residency (GDPR, Schrems II, India DPDP, China DSL) — personal data must stay within a jurisdiction.
- Latency — operational systems serving users in APAC should not query a US warehouse for every request.
- Resilience — a regional outage should not take the business down.
The hard part is reconciling these constraints with the analytical need to see across regions for global reporting.
Why it matters
Most multi-region architectures end up in one of three failure modes:
- Hub-and-spoke that violates residency — pulls all regional data to a central US or EU warehouse, breaking the residency promise.
- Federated queries that don’t perform — leaves data in-region but cross-region queries are too slow to be useful.
- Replicated everything — copies all data to every region, doubling storage cost and creating consistency nightmares.
The right architecture chooses which data is regional, which is global, which is privacy-shielded, and applies different patterns to each.
How it works
Three useful primitives:
- Regional data zones — each region has its own bronze and silver layers; raw and PII data never leave the region.
- Privacy-shielded gold — global gold layer aggregates that have been anonymized or pseudonymized at source.
- Federated query — for cases where global aggregation needs row-level reach, federation engines query in-region without moving the data.
A typical pattern:
- Regional bronze and silver in each region’s local cloud account.
- Privacy-shielded outputs replicated to a central global gold layer.
- Federated query (Trino, Snowflake Iceberg, Databricks Lakehouse Federation) for the rare cross-region row-level need.
- Catalog and lineage are global, even when data is regional.
Vendor comparison
| Aspect | Snowflake | Databricks | BigQuery | Confluent |
|---|---|---|---|---|
| Multi-region replication | Replication groups, failover, read-only replicas | Delta Sharing across workspaces | Multi-region datasets | Cluster Linking, Replicator |
| Federation | External tables, Iceberg federation | Lakehouse Federation | BigQuery Omni (cross-cloud) | Native (event-driven) |
| Residency control | Region-specific accounts | Region-specific workspaces | Region-locked datasets | Region-specific clusters |
| Catalog | Snowflake Horizon | Unity Catalog (global) | Dataplex | Stream Catalog |
Snowflake. Mature for multi-region in single-cloud deployments. Replication groups with failover are well-tested. Cross-cloud is harder.
Databricks. Unity Catalog is genuinely global — the same catalog can govern workspaces across multiple regions and clouds, which makes the residency story cleaner. Lakehouse Federation lets you query data that lives in other warehouses without copying it.
BigQuery. Multi-region is native to GCP; BigQuery Omni extends to AWS and Azure for read patterns. Strong if the organization is GCP-led.
Confluent. When the architecture is event-driven, Cluster Linking is the right primitive — replicate topics across regions, consume locally.
Yoann’s take
In the engagements I lead, multi-region is rarely about technology and almost always about ownership. The technology pattern that wins is regional bronze and silver, privacy-shielded global gold, and federated query for the long tail of cross-region needs. Unity Catalog has been the most useful single primitive for this shape because the catalog stays global even when the data does not. I treat replicate-everything architectures as a smell: they usually mean the residency posture was never seriously analyzed.
— Yoann