Where to Store EU User Data: What GDPR Actually Requires

A security questionnaire arrives from a customer you want to close, and two of the questions stop you: "Where is our data physically stored?" and "Is any personal data transferred outside the EU?" If you have to go and find out, the honest answer is usually more complicated than you'd like. Your database is in one place, its backups somewhere else, your file storage on a third provider, and your error tracker on a fourth. Suddenly a deal is waiting on a map of where every copy of the data actually lives.

This is the practical version of that map, written for the founder or engineer who has to answer the question rather than litigate it. It covers what GDPR really says about storage location, what "data residency" means once you look past the primary database, why storing EU data in the US got legally awkward, and a way to decide where your data should live without a legal department. None of it is legal advice, but all of it is the context that makes the legal advice fast.

Does GDPR actually require you to keep data in the EU?

The short answer surprises people: no. GDPR contains no blanket rule that personal data must physically stay inside the European Union. There is no line that says "store it in Europe." What the regulation controls is something narrower: the transfer of personal data out of the EU to a country that isn't covered by EU data-protection law.

That's the subject of Chapter V of the GDPR (Articles 44 to 49). The rule it sets is conditional: you may transfer personal data to a country outside the EU, but only if there's a legal mechanism behind it. That mechanism is one of three things: an adequacy decision from the European Commission that says the destination country protects data to an EU-equivalent standard (Article 45), appropriate safeguards such as Standard Contractual Clauses signed between the parties (Article 46), or one of the narrow situational exceptions in Article 49.

So the accurate framing is this: you can store EU personal data outside the EU, but the moment you do, you take on the transfer-mechanism problem: you have to have one and be able to show it's still valid. Keeping the data inside the EU is simply the way to make that entire problem disappear. There's no third country, no adequacy question, no clauses to maintain. That's why "data residency" and "GDPR compliance" get fused together in people's heads: residency isn't a legal requirement, it's the shortcut past the hardest part of the law.

What data residency actually means

Once you accept that residency is worth having, the next trap is thinking it's about where your primary database happens to run. It isn't. Data residency is a property of every copy of the data, and a running application produces a surprising number of copies.

• The primary database, plus any read replicas you've spun up for scale.
• Automated backups, WAL archives, and point-in-time-recovery snapshots, which are full copies of your data and easy to forget.
• Object storage for user uploads and media, plus any cross-region replication it does for durability.
• Caches and session stores — a Redis instance holding session tokens is holding personal data.
• Logs and their aggregation, which routinely capture request bodies, IP addresses, and user identifiers.
• Your CDN's origin and edge caches, and where it keeps its access logs.
• Every subprocessor your providers use underneath — the cloud your host runs on, the region your email vendor sends from.

The failure mode is almost never the obvious one. It's a provider whose control panel shows "Frankfurt" while its backups replicate to a US region for safety, or a CDN that serves European users from the edge but pulls from a US origin and writes its logs there. Residency is the answer to "where does every copy of this data end up," not "which region did I pick at signup."

Why "just store it in the US" got complicated

For a long time the pragmatic answer was to run on a big US cloud and rely on whatever transfer framework was in fashion. That path got rougher in July 2020, when the Court of Justice of the EU issued its ruling in the case commonly known as Schrems II. The court struck down the EU-US Privacy Shield, the adequacy framework that thousands of companies had relied on to move data across the Atlantic. Overnight, that easy legal basis was gone.

Standard Contractual Clauses survived the ruling, but with a condition attached: you can't just sign them and move on. You're expected to assess whether the destination country's laws actually let you honour them (a transfer impact assessment) and add supplementary measures where they don't. That's real work, and the burden sits with you, the data exporter.

In July 2023 the Commission adopted a new adequacy decision for the EU-US Data Privacy Framework, which restored a cleaner legal path, but only for US organisations that self-certify under it, and against a backdrop where the two previous US frameworks were both eventually invalidated in court. A challenge that people already call "Schrems III" is widely expected. Storing EU data in the US is legal today, but it rests on a framework with a track record of being struck down and re-negotiated.

Keeping the data in the EU doesn't depend on any of that machinery. There's no adequacy decision to watch, no clauses to keep current, no assessment to redo when the legal ground shifts. The trade is straightforward: US storage is legal but fragile and high-maintenance; EU storage is legal and stable. For most teams that don't have a specific reason to be in the US, the second one is a lot less to think about.

Where EU data leaks out without you noticing

If you decide you want EU residency, the work isn't picking a region. It's finding the copies that quietly leave it. These are the usual places EU data slips across a border while the main database sits obediently in Frankfurt:

• A managed database that keeps read replicas or automated backups in a non-EU region — the live data is in the EU, the copies aren't.
• Object storage configured to replicate buckets to a US region for durability, so every uploaded file exists on both sides of the Atlantic.
• A CDN that caches at European edges but fetches from a US origin, or writes its access logs, full of IPs and request paths, to US infrastructure.
• Analytics, error tracking, and session-replay tools that ship event payloads and stack traces to US servers by default.
• Transactional email and SMS providers that route messages, and keep delivery logs, through non-EU infrastructure.
• Support desks and CRMs where a copy of your users' personal data lands in a US tenant the moment a ticket is opened.

Each of these is a transfer under Chapter V, and each needs its own legal basis. This is exactly the gap Schrems II is about: the data doesn't leave through the front door, it leaves through a subprocessor two layers down. It's also why a stack assembled from a dozen mixed-region services is genuinely hard to answer for: the honest response to "does any personal data leave the EU" requires you to know the footprint of every vendor, not just your own database.

A practical way to decide where to store EU user data

You don't need a policy document for this. You need to answer a few questions in order and let the answers point at the setup.

1. Map the data. Write down what personal data you hold and where each copy lives — database, backups, file storage, logs, and every third-party service that touches it. Most of the risk is in copies you forgot you were making.
2. Decide whether you actually need strict residency. EU enterprise customers and their security reviews will usually want a firm "it stays in the EU." A side project with no EU B2B pipeline may reasonably care less. Be honest about which you are rather than over- or under-engineering it.
3. If you're keeping it in the EU, choose providers that run and back up inside the EU with no non-EU replication, and read their subprocessor list before you commit — that's where the leaks hide.
4. If you genuinely need a US service, treat it as a transfer: get that specific vendor covered by a mechanism (DPF certification or SCCs plus a transfer impact assessment), and accept that you've taken on its legal fragility.
5. Get the DPA either way. Residency answers "where" the data lives; the Data Processing Agreement answers "under what terms" it's handled. You need both.

One honest caveat worth stating plainly: residency is not the same as compliance. Keeping every byte in Frankfurt doesn't give you a lawful basis for processing, a way to handle data-subject requests, or adequate security on its own. What it does is remove the single hardest and least stable question (international transfers), so the rest of your compliance work isn't sitting on shifting legal ground.

The simplest answer: an EU-only stack

The reason residency turns into an audit is fragmentation — a database here, backups there, files on a third service, each with its own region settings and its own subprocessors. The unglamorous fix is to keep the whole stack in one EU region, so there's simply nothing to transfer and nothing to reconcile.

That's how Runsite is set up. Managed PostgreSQL keeps the instance, its WAL archive, and every automated backup and point-in-time-recovery snapshot in Frankfurt, Germany, so a restore never pulls data across a non-EU boundary. S3-compatible object storage holds your files in the same region, encrypted at rest with AES-256 and never replicated to a non-EU region. Public assets are served through a CDN, private ones through time-limited presigned URLs. A signed GDPR Data Processing Agreement comes with every plan, so the "under what terms" question is answered too.

When the database, its backups, and your file storage all sit in the same EU region, that security questionnaire stops being a research project. "Where is our data physically stored?" has one answer, and "does any personal data leave the EU?" is a plain no. Not because you audited a sprawl of vendors, but because there was never a copy anywhere else to begin with.

The short version

GDPR doesn't force you to store personal data in the EU; it regulates transfers out of it, and every such transfer needs a legal mechanism whose stability you don't control. Data residency, keeping every copy inside the EU, is the shortcut past that whole problem, and it's a property of your entire footprint (backups, replicas, logs, CDN, and subprocessors), not just the primary database. Work out whether your customers need strict residency, map where each copy actually lives, and if the answer has to be "in the EU," the least fragile way to get there is a stack that never leaves it. Run your database and storage in one EU region, and the next time a security review asks where the data lives, the answer is already one line.