Multi-region does not mean redundancy

This one cost me a revision to a document I had already circulated, so I’ll pass it on.

Create a BigQuery dataset in the US multi-region and it is easy to assume you are getting replication across US regions, and therefore some resilience against a regional outage.

You are not.

What a multi-region actually is

Google’s documentation is explicit that multi-regions do not provide regional redundancy. Data in the US multi-region lives in one of two regions — Iowa or Oregon — chosen automatically. A multi-region dataset and a regional dataset both hold two zonal copies inside a single region.

Choosing the multi-region over a specific region buys you larger quotas. It does not buy resilience. And if your infrastructure is in Virginia, your data isn’t near it.

Actual geo-redundancy requires explicitly configuring cross-region replication to a region you name. That is a separate design decision with its own cost, and its own residency implications — the secondary region is another jurisdiction question, and it needs answering before the replication is configured rather than after.

Why the assumption survives

The word does the damage. “Multi-region” reads as a stronger guarantee than “region,” so nobody checks. It appears in a design document as a resilience measure, passes review because it looks like one, and sits there unexamined until an outage or an auditor asks what it actually provides.

I would suggest searching your own design documents for the phrase. It was in one of mine.

The related trap

While you are in there, two properties of dataset location are worth confirming you have accounted for:

• Location is immutable. You cannot move a dataset. Changing it means creating a new one, copying the data, and cutting consumers over — an unfunded migration by another name.
• Queries cannot span locations. A dataset in one location cannot be joined to a dataset in another. Full stop.

Both are cheap decisions at intake and expensive ones after the data has landed.