The Data-Residency Fiction

Data residency shows up in nearly every enterprise contract and compliance review. The customer asks where their data lives. The vendor says the right region. Everyone moves on.

Underneath, the promise is often aspirational. A single primary database in one region serves the world, and "residency" means a clause in a document rather than a rule the system actually follows.

Routing and storing data by jurisdiction is genuinely hard with traditional infrastructure. It usually means standing up parallel stacks per region and adding routing logic nobody wants to own. So teams assert residency and hope the question never gets audited.

When your logic runs at the edge, you know where a request originates before you decide where its data goes. You can route a write to the database that physically lives in the matching region, and you can store objects under a jurisdiction that enforces the boundary.

That changes residency from a sentence in a contract into behavior you can demonstrate. The system does the right thing at request time, and you can prove it.

I provisioned two Cloudflare D1 databases with location hints, one in Western Europe and one in North America, plus a small schema applied to both. A Pages Function reads the request region and writes the record to the database that matches the jurisdiction.

A records endpoint then shows which database actually holds the row. You can submit a write as an EU user and a US user and watch the data land in two different places. Residency you can point at, not just claim.