Today, MongoDB is announcing the public preview of data residency in Europe and the US for the Embedding and Reranking API Service, also known as ERAS, on MongoDB Atlas. It’s a critical priority to make industry-leading Voyage AI models available wherever our customers operate, while meeting their strictest regulatory requirements. The introduction of geography-specific data residency builds on the strong foundation of MongoDB Atlas’s enterprise-grade data privacy, security, and compliance features, and will help organizations operating in Europe meet local data sovereignty requirements when building AI-powered search into their applications.
Regions and Geographies
When you provision a database cluster in Atlas, you choose a cloud provider region, and that determines where the cluster's data is stored and processed. With today’s update, we are introducing a second boundary called a Geography: a named group of cloud regions inside which MongoDB will process the content you submit for embedding, reranking, and related model calls. The first two supported Geographies are Europe and the United States, with plans to expand to future Geographies soon.
The Europe Geography initially covers cloud provider regions in the European Economic Area, The United States Geography initially covers cloud provider regions in the United States. The set of regions inside a Geography can change, which is why the boundary is drawn at this level rather than at the region level.
What we commit to
A Designated Service is a service that honors the Geography scope applied to your model API key. When you send a scoped request to a Designated Service, inference for that request runs inside the Geography.
When you select a Geography for a Designated Service, four things hold:
Inference on the content you submit runs on GPU-accelerated compute inside that Geography.
Request payloads we retain for logging are stored inside that Geography.
Every request is tagged with the Geography that served it, so usage records and invoices can be filtered and audited along that dimension.
If the Geography cannot serve a request, the request fails rather than falling back somewhere else.
The fourth commitment is deliberate and stricter than the common industry pattern, which allows an administrator to opt into cross-boundary processing when a service is unavailable locally. Under MongoDB’s new data residency commitment, traffic sent to the Europe endpoint is served in Europe or not at all. The tradeoff is that a scoped endpoint depends on capacity in one Geography rather than a global pool, which is why scoping is something to turn on only where a requirement calls for it, rather than everywhere by default.
Why boundaries use Geographies rather than Regions
GPU-accelerated compute is not evenly distributed. It is concentrated in a subset of cloud regions, and that concentration is a durable property of the market rather than a temporary shortage. Committing at region granularity would mean either making do with a very short list of supported regions or making a commitment carrying enough exceptions to be worth little.
Committing at Geography granularity avoids that. It is a boundary we can hold as capacity moves between regions, without renegotiating the promise each time. It also matches how the obligations customers cite tend to be written. European data protection requirements are generally expressed at the Union or EEA level (rather than against an individual member state), so a boundary drawn there is usually the boundary that matters.
Selecting and enforcing a Geography
For direct API calls, scope is carried by the API key and expressed in the endpoint. Keys are immutable, so the scope is fixed at creation, and changing it means creating a new key. Existing keys continue to work unchanged against the general endpoint.
For enforcement, resource policies can restrict key creation to a chosen Geography across an organization, so a developer cannot create an out-of-scope key in the first place, and keys that fall outside a newly applied policy are flagged. Automated Embedding and Native Reranking will get equivalent mechanisms when they ship.
The general, unscoped endpoint remains the default recommended path for workloads without a residency requirement, and is where we will perform global load-balancing in the future. Scoped processing carries a 10% price premium, reflecting the higher cost of accelerated compute that cannot draw on the global pool.
Example request flow
Here’s what an example request looks like, using Atlas ERAS on the Europe Geography:
Your application calls an EU-scoped endpoint rather than the general one.
The request is routed into the inference stack for Europe.
The gateway ensures that your API key is scoped for Europe.
Note: An API key and an endpoint must align in scope. An unscoped key cannot be used for explicit EU inference, and vice versa.
Rate limits are applied for that scope.
The content is tokenized and dispatched to model servers running on accelerated compute inside Europe.
The response is assembled and returned. Any retained payload logging is written within Europe.
Steps 3 through 6 all happen inside the boundary. The scope check is done twice, against the key prefix and against the key's stored attributes, so a misconfigured client cannot route content out of its intended Geography by accident.
What coordinates globally, and what this doesn’t address
A small set of account metadata is shared across Geographies so that one Atlas account works everywhere: org, project, and API key IDs and the scope attached to them, resource policies, rate limit configuration, and usage data. None of it contains the text, documents, or images you submit for inference. Those are processed and logged only within the Geography you selected.
Note, however, that Geography scoping is a processing boundary. It is separate from data retention, so if your requirement is that we retain nothing rather than that we process locally, that is a different conversation and one worth having explicitly. It also does not cover in-country or single-region processing, air-gapped or self-managed deployment, or open-weight models you can audit yourself.
Next Steps
Get started today through our documentation.