Data Residency Is a Replication Topology, Not a Dropdown

• Introduction — The Question a Region Dropdown Cannot Answer
• A Company Published Its Whole Replication Topology
• Data Lives in Seven Places, Not One
• Choose Availability and You Lose Residency
• Jurisdiction Attaches to the Legal Entity, Not the Location
• How Migration Is Handled Is Information Too
• What to Actually Ask a Vendor
• Turning the Same Questions on Our Own System
• References

Introduction — The Question a Region Dropdown Cannot Answer

You have probably written the line "customer data is stored within the EU" in a security review document. And the evidence behind that sentence is usually the single fact that somebody picked EU from the region dropdown in a vendor console.

To confirm whether that sentence is true, you need answers to at least seven questions. Where is the primary copy. Where are the replicas. Where are the backups. Where is the metadata that gets referenced globally. Where are the logs. Which third parties are used for billing and support. And when the EU region dies, where does your client connect to.

What makes the post Fastmail wrote on August 3, 2026 when it announced its EU data region useful is that it writes down answers to all seven. Including the answers that are inconvenient for marketing.

This is not a post recommending Fastmail. It is a post saying use that document as the baseline for vendor due diligence.

A Company Published Its Whole Replication Topology

First, how this company is set up. Fastmail does not rent cloud; it runs its own hardware in colocation. In the original phrasing it specifies "down to the disk model that goes into each machine," and it writes that on top of the existing Philadelphia and St. Louis sites it installed servers in Amsterdam to the same standard.

The replication policy is written down as it stands too. For a long time it has kept "at least two copies of every user's mail on different servers at the primary location, plus at least one more in a geographically separate location."

That one sentence already contains the answer. A policy of maintaining geographically separated copies and a policy of data staying in only one region cannot both hold at once. The durability requirement by itself makes residency plural.

So the honest sentence a company opening an EU region can say is not "your data is in the EU" but "the primary copy is in the EU." Fastmail actually writes it that way.

Data Lives in Seven Places, Not One

Organizing the items in the original that apply to an EU region account gives this.

What the region dropdown changes is one line, the first one, in this table. The other six lines stay as they are.

The fourth line matters especially. The original enumerates the globally replicated items concretely: user and customer metadata including email addresses, storage for the website and standalone files features, and the details of connected third-party services. In other words it states outright that "some data for everyone is in both Europe and the US."

This category exists in your system too, without fail. Account lookup tables, routing rules, feature flags, plan information. These are the things kept global because of latency, and they are the things discovered last in a region separation design.

Choose Availability and You Lose Residency

There is a sentence in the original like this. "We prioritise availability. So if your home location goes down, you will temporarily connect to one of our other locations and keep accessing your data."

This is the trade-off most often ignored in data residency design.

Which is worse, not being able to open your mailbox, or your data briefly crossing the Atlantic? For most users the former is far worse. So most services make the same choice. Most just do not write that choice down in a document.

The moment you write "data does not leave the EU" into a contract, you have also promised to take the service down during an EU region outage. You need to check whether you are prepared to keep that promise, and whether you explained the trade-off to the customer that way.

Mail routing has the same problem. The original writes that if you use Fastmail nameservers on your own domain or use a region-specific domain, incoming mail goes "preferentially" to that region's servers. Conversely, if you use a generic domain with no region, mail can come and go either way. Connection hostnames are the same: a generic IMAP hostname is proxied internally to the active server, and to control where you connect you have to use the region-specific server name.

Picking EU in a settings screen does not make the protocol paths EU.

Jurisdiction Attaches to the Legal Entity, Not the Location

This is the most candid passage in the document.

Fastmail states that it is an Australian company and is subject to Australian law, including legal cooperation treaties between Australia and other countries. And it writes this: "Wherever the data is stored, we will respond in the same way to lawful requests from relevant authorities."

The sentence that follows is worth quoting. "If what you need is a guarantee that data remains only in the EU, we do not have that. And rather than let you assume otherwise, it is better to say it directly."

This is where data residency and data sovereignty part ways.

• Residency is a technical property. Which building are the disks in. It can be changed by configuration.
• Sovereignty is a legal property. Who can compel that data to be handed over. It depends on which country's law governs the legal entity that controls the data, and it does not change with a region setting.

Even if you put data in an Amsterdam data center, if the company operating that data is subject to another country's law, that country's lawful requests remain valid. If you truly need sovereignty, what you need is not a region but a legal entity in a separate jurisdiction, or end-to-end encryption that the operator cannot decrypt.

How Migration Is Handled Is Information Too

It is a detail, but there is something to learn from a design point of view.

Fastmail writes that it pre-selected the EU region for users whose billing address is in Europe or nearby, that it moved encrypted copies to Europe before the announcement, and that it will soon promote them to primary. Users who signed up recently were assigned to the US and can change it in settings.

And it makes explicit that the cost differs by direction. Moving from the US to the EU is slow because there is no copy in that region, so all mail has to be synchronized across the Atlantic; moving back from the EU to the US is fast because a copy already exists in the US and only needs to be reconciled.

This asymmetry follows directly from the replication topology, because the replica of an EU account is in the US. Know the topology and migration cost becomes predictable; do not know it and it does not. Put this question to a vendor that describes a region move as "one setting" and the depth of the answer will separate them.

The switching path is documented too. Under Users & Sharing in settings, in Team Settings, there is a data residency section beneath the GDPR item, where you can see pending, in-transit, and completed states, and it says the account keeps working during the move.

What to Actually Ask a Vendor

Turn the above straight into a questionnaire and it comes out like this. A good number of vendors have prepared answers only for the first two or three.

1. Where is the primary copy stored? (nearly every vendor answers this)
2. Where are the live replicas? How many?
3. Where are the backups? Is the backup location a different region from the primary copy?
4. Is there data replicated globally regardless of region? If so, please give me the list.
5. Where are the logs stored, and do the logs contain personally identifiable information?
6. Are there third parties used for billing, support, or error tracking? What is passed to them?
7. When the primary region fails, where do requests go? Where does the data move at that point?
8. In which country is your company incorporated, and whose lawful requests do you honor?
9. Do you have a transparency report?

The conversation often stops at four and five. That is not because the vendor is bad but because nobody in the sales organization knows those answers. These questions have to be relayed to engineering, and the very fact that the answer takes time is itself information.

Turning the Same Questions on Our Own System

Finally, I recommend applying this questionnaire to your own system. It usually falls apart in the following order.

Logs come first. Few organizations keep application logs separated by region. Observability tooling defaults to collecting everything in one place, and those logs contain user identifiers, IP addresses, and sometimes parts of request bodies.

Backups come second. Cross-region replication on an object store is often turned on for durability and then forgotten. Go check whether it is on.

Analytics and error tracking come third. Code that sends events from the frontend directly to an external SaaS bypasses the entire backend region design.

Administrative access comes fourth. Even if the data is in the EU, if an operator connects from another region and queries it, under which regulation does that query happen? This item is not a technical setting but a matter of access control and audit logging.

The reason the Fastmail document is a good document is that while selling an EU region it wrote first that "there is no guarantee it stays only in the EU." Your security review document is worth aiming at the same standard. Writing a sentence you can keep, precisely, is far better than writing one you cannot.

References

• Fastmail offers EU data region — Bron Gondwana, 2026-08-03 (all the quotations and the table in this post are carried over from this document)
• Choosing your data residency — Fastmail help
• Fastmail transparency report