AWS DocumentDB EU Alternative 2026: MongoDB Compatibility, Oplog Exposure, and the CLOUD Act Problem

Post #779 in the sota.io EU Compliance Series

AWS DocumentDB is Amazon's fully managed document database service offering MongoDB wire protocol compatibility. It powers JSON-document workloads at scale — user profiles, product catalogues, event logs, content management systems, and IoT device state stores. For teams already running MongoDB locally or on Atlas, DocumentDB is often positioned as the path-of-least-resistance migration to managed AWS infrastructure.

AWS operates DocumentDB in Frankfurt (eu-central-1) and Stockholm (eu-north-1). It ships with the standard AWS GDPR Data Processing Addendum and Standard Contractual Clauses. Most migration guides treat Frankfurt deployment as sufficient for EU compliance.

The problem is structural. Amazon Web Services, Inc. is incorporated in Delaware and is a wholly-owned subsidiary of Amazon.com, Inc., a US corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) requires every US-incorporated provider to comply with US government data orders regardless of where the servers sit. A valid CLOUD Act order can compel disclosure of your entire DocumentDB cluster — every collection, every document, every version retained in the oplog — without involving a European court, without advance notice, and potentially under a gag order.

But DocumentDB's GDPR risk extends beyond the base jurisdiction problem. The service's change stream architecture creates a structured, durable audit log of every document mutation — a secondary PII store that outlives deletion operations and that GDPR Art.17 erasure requests cannot fully address.

This post analyses DocumentDB's GDPR and CLOUD Act exposure across its full service stack and maps the best EU-native managed document database alternatives for 2026.

What DocumentDB Actually Stores — and What Changes Streams Capture

DocumentDB's GDPR exposure surface includes four distinct data layers, each with separate retention characteristics.

Primary collections: Your documents, structured as BSON (Binary JSON), stored in collections within databases. In a typical SaaS or e-commerce workload, these contain: user profiles (name, email, address, preferences), order history, session records, device identifiers, geolocation data, and behavioural signals. All of these are personal data under GDPR Art.4(1).

Change streams (the oplog layer): DocumentDB supports change streams — a MongoDB-compatible mechanism for subscribing to real-time document change events. Under the hood, change streams are built on DocumentDB's internal oplog (operations log), which records every insert, update, replace, and delete operation as a structured event. Each change stream event contains:

• The operation type (insert, update, replace, delete)
• The full document before the change (the fullDocumentBeforeChange field, when enabled)
• The full document after the change (the fullDocument field)
• The namespace (database + collection)
• A wall-clock timestamp
• A resume token for cursor continuity

This means that if you enable change streams — for audit logging, event sourcing, or real-time sync — your DocumentDB cluster accumulates a structured, time-ordered record of every PII modification. The oplog retention window in DocumentDB is configurable (default: typically hours to days depending on cluster size), but in long-running production clusters it can span months. The oplog is itself a personal data store under GDPR, subject to all data minimisation, storage limitation, and retention obligations.

Automated backups and point-in-time recovery snapshots: DocumentDB automatically creates daily snapshots and retains them for a configurable period (1–35 days). Point-in-time recovery allows restoration to any second within the retention window. Each snapshot is a complete copy of your cluster at that moment. Under CLOUD Act, every snapshot is reachable. Under GDPR Art.17, this creates an erasure paradox: when a user exercises their right to erasure, you can delete the document from the live collection — but every automated snapshot created before that deletion continues to contain the user's data. The deleted data persists in snapshot storage until those snapshots age out of the retention window.

Audit logs (optional): DocumentDB supports audit logging to CloudWatch Logs. When enabled, the audit log captures authentication events, DDL operations, and DML operations against the cluster. CloudWatch Logs is itself a separate AWS service with its own retention settings, subject to the same CLOUD Act jurisdiction.

GDPR Art.17 and the Snapshot Erasure Gap

The GDPR Art.17 right to erasure ("right to be forgotten") requires controllers to erase personal data "without undue delay" when the data subject requests deletion and no legitimate retention ground applies.

DocumentDB's automated backup architecture creates a structural gap in erasure compliance.

When you delete a document from a live DocumentDB collection, the deletion is immediate in the primary storage layer. From a live-query perspective, the data is gone. But the deletion event itself is recorded in the oplog as a delete change stream event — meaning the oplog retains a record that this document existed and was deleted, along with the resume token that identifies the document. If you have fullDocumentBeforeChange enabled on your change stream, the oplog event contains the entire document as it existed immediately before deletion.

More fundamentally: all automated snapshots created before the deletion continue to contain the document. A cluster with a 35-day point-in-time recovery window will retain deleted personal data in snapshot storage for up to 35 days after the erasure request. During that window, the data is:

• Stored at rest in AWS S3 (the underlying snapshot store)
• Subject to CLOUD Act disclosure
• Not accessible via normal queries, but restorable by an AWS operator or via the restore-db-cluster-to-point-in-time API

Whether this residual snapshot retention constitutes a GDPR Art.17 violation depends on the specific circumstances. Supervisory authorities have generally accepted that backup copies may take time to purge, provided the organisation has a documented process and a defined maximum retention period. However, if your 35-day snapshot window causes personal data to persist significantly longer than the purpose originally required, you face a GDPR Art.5(1)(e) storage limitation argument in addition to the Art.17 question.

If you use DocumentDB for data that is subject to strict erasure SLAs — for example, because your terms of service promise data deletion within 72 hours — the snapshot retention architecture is incompatible with that commitment without manual snapshot deletion as part of your erasure workflow.

GDPR Art.5(1)(c): The Change Stream Data Minimisation Problem

GDPR Art.5(1)(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" (data minimisation). Art.5(1)(e) requires that it be "kept in a form which permits identification of data subjects for no longer than is necessary" (storage limitation).

Change streams create a systematic data accumulation pattern that challenges both principles.

When organisations implement change streams for audit logging, they typically capture all mutations across all collections. This is architecturally straightforward — one change stream listener per cluster, one log destination, full coverage. The problem is that "full coverage" means accumulating a complete PII mutation history indefinitely, for operational purposes (debugging, compliance auditing, replication sync) that may not require the full document content.

A GDPR-minimised audit log would record that an event occurred, when, by whom, and what type of operation — without the full document payload. But DocumentDB's change stream events include the full document by default. Disabling fullDocument and fullDocumentBeforeChange reduces this exposure but removes the payload that most audit use cases actually require.

The data minimisation tension is structural: the operational value of change streams comes precisely from the richness of the event payload. Reducing that payload to satisfy Art.5(1)(c) degrades the operational utility that motivated enabling change streams in the first place.

GDPR Art.44 and DocumentDB Global Clusters

DocumentDB global clusters allow you to span a DocumentDB deployment across multiple AWS regions, with one primary region handling writes and up to five secondary regions receiving replicated reads. Global clusters are designed for global applications requiring low read latency and disaster recovery with cross-region failover.

For EU data controllers, the Art.44 analysis is simple: adding any non-EU region to a DocumentDB global cluster constitutes an international transfer of personal data. The secondary region receives a continuously updated replica of your entire EU dataset — every collection, every document.

Within the EU, global clusters across Frankfurt and Stockholm create no Art.44 issue. Both regions are within the EEA. This is a valid multi-region architecture for EU data.

Adding a non-EU secondary — US East, US West, Asia Pacific — triggers Art.44. Standard Contractual Clauses are available, but SCCs for intra-AWS transfers do not address CLOUD Act exposure: a US region copy of your EU dataset is reachable by US government orders independently of the Frankfurt copy.

DocumentDB does not enforce region restrictions on global cluster topology. Nothing prevents an administrator from adding a us-east-1 replica to a cluster containing EU personal data. Your Art.44 compliance depends entirely on IAM policies and organisational controls preventing that configuration.

MongoDB Atlas: EU-Hosted but Not EU-Sovereign

Before evaluating alternatives, it is worth addressing MongoDB Atlas directly. Many architects migrating away from DocumentDB consider Atlas the natural destination — it is the genuine MongoDB product, whereas DocumentDB is a compatibility layer.

MongoDB Atlas offers deployment in Frankfurt (AWS eu-central-1) and Stockholm (AWS eu-north-1). MongoDB, Inc. provides a GDPR DPA, SCCs, and a dedicated EU data residency commitment.

The CLOUD Act problem applies. MongoDB, Inc. is incorporated in Delaware and headquartered in New York. Under CLOUD Act §2713, MongoDB, Inc. is a US-incorporated provider required to comply with US government data orders. A valid CLOUD Act order can compel MongoDB to disclose EU-hosted Atlas data, regardless of MongoDB's EU legal entity structure or DPA commitments.

For organisations whose threat model includes US government access — which the EDPB and national supervisory authorities have consistently indicated is a realistic concern — MongoDB Atlas on AWS infrastructure is not a genuine departure from DocumentDB's jurisdictional exposure.

EU-Native DocumentDB Alternatives for 2026

FerretDB (Open Source, Any EU-Native Host)

FerretDB is an open-source MongoDB wire protocol implementation built on top of PostgreSQL. It accepts the same MongoDB drivers and connection strings as DocumentDB, enabling migration without application code changes. FerretDB is MIT-licensed and maintained by an independent open-source community — no US parent company, no CLOUD Act attachment.

Deployed on EU-native infrastructure — on-premises, or on a EU-native managed Kubernetes platform — FerretDB gives you full MongoDB compatibility with complete data sovereignty. The underlying PostgreSQL storage inherits PostgreSQL's mature GDPR tooling: row-level security, column-level encryption, pg_partman for retention management, and precise point-in-time recovery controls.

FerretDB's production maturity is evolving rapidly (v2.x as of 2026). It is suitable for most document workloads, though extreme write-throughput workloads may still require benchmarking before migration.

Ideal for: Teams that want MongoDB wire protocol compatibility with full stack control and EU-sovereignty. Deployable on sota.io (EU-native managed PaaS) or any EU-hosted Kubernetes cluster.

Percona Server for MongoDB (Self-Hosted, EU-Native Infrastructure)

Percona Server for MongoDB is the fully open-source, drop-in replacement for MongoDB Community and Enterprise editions. Unlike DocumentDB, Percona is the actual MongoDB engine — WiredTiger storage, native replica sets, genuine oplog semantics — not a compatibility layer. Percona's enterprise features (encrypted backups, audit logging, in-memory storage engine) ship open-source without a proprietary lock-in.

Deployed on EU-native infrastructure — bare metal in an EU colocation facility, or on an EU-native managed platform — Percona gives you MongoDB without the CLOUD Act. Your backup toolset (Percona Backup for MongoDB) is yours to operate and store wherever you choose. Point-in-time recovery targets can be EU-sovereign S3-compatible stores (MinIO, Hetzner Object Storage, OVHcloud Object Storage).

Ideal for: Organisations running high-volume MongoDB workloads that need the genuine engine, not a compatibility layer, and can operate their own cluster infrastructure.

PostgreSQL with JSONB (EU-Native Managed, Full GDPR Tooling)

For workloads that chose DocumentDB for its flexible schema rather than for the MongoDB query API, PostgreSQL with JSONB is a powerful EU-native alternative. JSONB columns support arbitrary JSON documents with full index support (GIN indexes for containment queries, expression indexes on frequently-queried paths). PostgreSQL's jsonb_path_query and standard dot-notation access cover the majority of document query patterns.

The GDPR advantage of PostgreSQL is its mature erasure tooling. Unlike DocumentDB's oplog-based change streams, PostgreSQL's logical replication can be configured to stream only non-PII fields. Point-in-time recovery uses WAL (Write-Ahead Log) segments stored wherever you choose. Encryption at rest, column-level encryption via pgcrypto, and row-level security are all available in open-source PostgreSQL — no additional license required.

Ideal for: Workloads migrating from DocumentDB for schema flexibility where the MongoDB query API is not a hard requirement. Deployable on any EU-native PostgreSQL managed service.

sota.io: EU-Native Managed Platform for Document Databases

sota.io is a EU-native managed PaaS for application and database deployment. Incorporated and operated exclusively within the European Union, sota.io falls outside the scope of the CLOUD Act. There is no US parent company and no CLOUD Act obligation.

On sota.io, you can run FerretDB, Percona Server for MongoDB, or PostgreSQL with JSONB as fully managed deployments — with Git-push deploys, environment variable management, and automated TLS. Your document data stays within EU jurisdiction at every layer: compute, storage, backup, and network.

For DocumentDB migrations, sota.io's FerretDB templates preserve your MongoDB connection string and driver compatibility while moving the jurisdictional exposure from AWS to an EU-sovereign operator.

What to Do If You Are Running DocumentDB Today

If you are currently operating DocumentDB in Frankfurt and processing EU personal data, the following steps address the most significant GDPR gaps:

Audit your change stream configuration. Determine whether fullDocument or fullDocumentBeforeChange is enabled. If yes, document the retention window and legal basis for accumulating full document payloads in the oplog. Consider whether your use case requires the full payload or whether metadata-only change events would satisfy your operational requirement.

Map your snapshot retention to your erasure SLA. If your privacy policy or DPA commits to personal data erasure within a specific timeframe, verify that your DocumentDB snapshot retention period is shorter than that commitment — or implement a snapshot deletion workflow as part of your Art.17 erasure process.

Audit your global cluster topology. If you have secondary regions, verify that all replicas are within the EEA (Frankfurt, Stockholm). Confirm that IAM policies prevent accidental addition of non-EU secondaries without a corresponding Art.44 process.

Assess your CloudWatch Logs retention for audit logs. If audit logging is enabled, confirm that CloudWatch log group retention is set to an appropriate period and that the retention is documented in your record of processing activities (Art.30 GDPR).

Plan for a jurisdictional move. The CLOUD Act risk is not addressable through AWS contractual measures. SCCs and DPAs do not override US statutory law. If your DPA analysis concludes that US government access is a realistic risk — which the EDPB's recommendations consistently indicate it is — migration to EU-native infrastructure is the structural fix.

Conclusion

AWS DocumentDB offers MongoDB wire protocol compatibility with AWS's operational reliability. For EU data controllers, the GDPR exposure is multilayered: the base CLOUD Act jurisdictional problem applies to every document and every snapshot; change streams create a secondary PII accumulation layer with its own retention lifecycle; and the automated snapshot architecture creates a structural Art.17 erasure gap.

FerretDB, Percona Server for MongoDB, and PostgreSQL with JSONB each offer a genuine path to EU-sovereign document storage — MongoDB-compatible or PostgreSQL-backed — without the CLOUD Act attachment. Deployed on EU-native infrastructure such as sota.io, these alternatives give you the document database semantics of DocumentDB with the jurisdictional guarantee that DocumentDB cannot provide.

The Frankfurt region label on your DocumentDB cluster is not a sovereignty guarantee. EU-sovereignty requires an EU-incorporated operator with no US parent — and a data access architecture that your DPIA can defend without relying on SCCs to override US statutory law.