AWS DynamoDB EU Alternative 2026: GDPR, CLOUD Act, and the NoSQL Jurisdiction Problem

Post #682 in the sota.io EU Compliance Series

AWS DynamoDB is Amazon's flagship managed NoSQL database — a fully serverless, key-value and document store that powers millions of production workloads. It offers single-digit millisecond latency at any scale, on-demand capacity, integrated caching via DAX, and change-data capture via DynamoDB Streams. For teams building on AWS, DynamoDB is frequently the default choice for session state, user profiles, gaming leaderboards, and event sourcing.

AWS operates DynamoDB in Frankfurt (eu-central-1) and Stockholm (eu-north-1). It provides the standard AWS GDPR Data Processing Addendum and Standard Contractual Clauses under GDPR Art.46. Many architects treat this configuration as compliant.

The problem is structural and the same one that applies to every AWS service: 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 directed at AWS can compel disclosure of your Frankfurt DynamoDB table contents, your Streams change records, your PITR backups, and your DAX cache — without involving a European court, without notifying you in advance, and potentially with a gag order that prevents AWS from telling you it happened.

This is the same structural issue documented for AWS RDS, AWS ElastiCache, MongoDB Atlas, PlanetScale, Neon, and Firebase. A geographic region is a statement about where the hardware sits. It is not a statement about who holds legal authority to compel disclosure under US federal law.

This post analyses DynamoDB's GDPR and CLOUD Act exposure across its full service stack — tables, Streams, PITR backups, Global Tables, and DAX — and maps the best EU-native managed NoSQL alternatives for 2026.

What DynamoDB Actually Stores

DynamoDB's GDPR exposure surface is broader than most architects assume, because DynamoDB is not just a database: it is an interconnected service stack with multiple independently queryable data planes.

Primary table data: Every item (row) you store in a DynamoDB table — user records, order states, session tokens, product catalogue entries, game states, audit logs. This is the obvious GDPR data surface.

DynamoDB Streams: A time-ordered log of every write to your table. Streams retain records for 24 hours. Many architectures use Streams to trigger AWS Lambda functions for real-time processing — analytics pipelines, notification systems, search index updates. The Stream record contains the old and new values of every modified item. This means that a CLOUD Act order targeting your DynamoDB table can also reach the change history of every record you have written or updated, including fields you subsequently deleted.

Point-in-Time Recovery (PITR) backups: DynamoDB PITR creates continuous backups that let you restore to any second within a 35-day window. These backups are stored as Amazon S3 objects in AWS-managed buckets in the same region. They are under the same CLOUD Act jurisdiction as the primary table and represent a 35-day historical window of your data, even if you have deleted records from the primary table.

DynamoDB Accelerator (DAX): Amazon's proprietary in-memory cache for DynamoDB. DAX sits in front of your tables and caches read results. Its data is a subset of your primary table, held in memory inside a DAX cluster in your VPC. DAX uses a proprietary protocol — there is no open-source equivalent — so DAX-specific caching logic requires rewriting when migrating to an EU-native stack.

On-Demand Exports to S3: DynamoDB's export feature allows you to export a full table snapshot to S3 in Amazon Ion format. The exported S3 objects inherit the jurisdiction of the S3 bucket — if you export to a bucket in us-east-1 for cost reasons, you have committed a GDPR Art.44 transfer.

Global Tables: DynamoDB's multi-region active-active replication feature. We analyse this separately below because it represents the most common accidental GDPR violation in DynamoDB architectures.

The CLOUD Act Exposure Pathway

The legal mechanism is 18 U.S.C. § 2713, which states that a covered provider "shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

The phrase "within such provider's possession, custody, or control" is the operative clause. AWS's operational control over its Frankfurt data centres is precisely this: AWS controls the hardware, the hypervisor, the network fabric, the key management infrastructure (KMS), and the operational tooling. AWS Inc. (Delaware) controls AWS Frankfurt through a corporate parent-subsidiary chain. Under CLOUD Act, the US government can order AWS Inc. to exercise that operational control to extract data — and Frankfurt's physical location is not a defence.

Relevant case law: In re: Search of Information Associated with Email Accounts (E.D. Va. 2017) established that US courts can compel production of data stored abroad by US-incorporated providers. The CLOUD Act was specifically passed to resolve the Microsoft Ireland case (United States v. Microsoft Corp., 584 U.S. 236 (2018)), where Microsoft refused to comply with a US warrant for data stored in Dublin. Congress's response was to explicitly extend US jurisdiction to overseas data.

AWS's own language: AWS's GDPR FAQ states that AWS will "scrutinise" government requests, challenge unlawful ones, and notify customers where legally permitted. "Where legally permitted" is doing significant work in that sentence. The Stored Communications Act, used as the basis for most CLOUD Act requests, includes gag-order provisions under 18 U.S.C. § 2705(b) that prohibit notification for periods of up to 90 days, extendable indefinitely with court approval.

The SCC workaround: GDPR Art.46(2)(c) Standard Contractual Clauses allow international data transfers if supplementary measures ensure an essentially equivalent level of protection. The European Data Protection Board's Schrems II guidance explicitly states that SCCs are insufficient where the recipient is subject to surveillance laws that override them — which is exactly what the CLOUD Act does. AWS acknowledges this in its own Supplementary Addendum by noting that CLOUD Act requests are binding under US law regardless of European contractual obligations.

DynamoDB Global Tables: The Accidental Art.44 Trap

DynamoDB Global Tables is the feature that has caused the most accidental GDPR violations in production DynamoDB deployments. Understanding why requires understanding how Global Tables work.

A Global Table is a multi-region, active-active replication topology. When you write an item in eu-central-1, DynamoDB automatically replicates that write to every other region in your Global Table configuration. Replication is asynchronous but typically completes in milliseconds.

The GDPR problem is simple: DynamoDB does not prevent you from adding a US region to a Global Table that contains EU personal data. The AWS console, the CLI, and CloudFormation all allow you to add us-east-1 or us-west-2 as a replica region with a single API call. If you do this — even accidentally, even briefly for a test — every item in your table is replicated to US-region hardware. This is an Art.44 GDPR international transfer.

The compliance issue does not stop there. Global Tables replicas in the same EU region (e.g., eu-central-1 and eu-north-1) do not escape CLOUD Act jurisdiction — both are operated by AWS Inc. (Delaware), so a CLOUD Act order can reach either replica.

The real risk of Global Tables for GDPR architects: teams configure Global Tables for disaster recovery, then later add a US replica for latency reasons when onboarding US customers. The GDPR implications of this architectural decision are often not flagged by cloud security tooling (CSPM tools track S3 bucket policies and security groups, not DynamoDB replica regions). By the time the DPO runs a DPIA, the US replica may have been replicating EU personal data for months.

DynamoDB Streams + Lambda: The Pipeline Jurisdiction Problem

A DynamoDB architecture that processes Streams via Lambda creates a data pipeline where GDPR jurisdiction extends to compute, not just storage.

When a Lambda function processes a DynamoDB Streams record:

1. The Streams record (containing old and new item values) leaves the DynamoDB service plane
2. It is delivered to the Lambda execution environment as an event payload
3. Lambda processes it in a managed container in AWS's compute infrastructure
4. The result may be written to another AWS service: SQS, SNS, OpenSearch, RDS, or S3

Every step of this pipeline is under CLOUD Act jurisdiction. A government order targeting "all data related to customer ID X" can reach not just the DynamoDB table but every intermediate processing stage in this pipeline.

AWS EventBridge Pipes — the newer AWS-native way to connect DynamoDB Streams to downstream services — has the same jurisdiction profile: it is an AWS-managed service operated under AWS Inc.'s Delaware incorporation.

DynamoDB Pricing as a GDPR Risk Factor

DynamoDB's on-demand capacity mode deserves a GDPR-specific mention that rarely appears in compliance guides.

In on-demand mode, DynamoDB automatically scales capacity up and down based on actual traffic. You pay per request rather than for provisioned capacity. AWS distributes the capacity across its fleet dynamically.

From a GDPR standpoint, on-demand mode makes it harder to assert that your data is processed in a fixed, audited infrastructure footprint. The distinction matters under GDPR Art.32, which requires "appropriate technical and organisational measures" including knowledge of processing locations. AWS's response is that on-demand capacity in eu-central-1 stays within that region's infrastructure — which is correct for the primary data path. But the capacity management plane (which determines how to allocate resources) runs in AWS's global control plane infrastructure, which is US-jurisdiction.

PartiQL: The SQL Facade That Hides a NoSQL Compliance Gap

AWS introduced PartiQL support for DynamoDB in 2020. PartiQL is a SQL-compatible query language that allows you to write SELECT * FROM "users" WHERE user_id = 'abc' against a DynamoDB table.

This feature has an unintended GDPR consequence: it makes DynamoDB look syntactically identical to a relational database in code reviews, DPIA documentation, and compliance audits. DPOs and lawyers reviewing data processing activities often see SQL-like syntax and assume a relational database with the expected GDPR properties (specific field-level retention policies, column-level encryption, row-level security).

DynamoDB with PartiQL is still DynamoDB. It still has DynamoDB's item-level structure, DynamoDB's lack of server-side column-level encryption (only item-level or full-table), and DynamoDB's Global Tables replication semantics. The SQL syntax does not change the underlying GDPR exposure.

The audit risk: A DPIA that describes the data store as "SQL-queryable NoSQL database" may pass initial review but fail a deeper audit when the auditor discovers that "SQL-queryable" means PartiQL on DynamoDB rather than a traditional RDBMS. Accuracy of technical descriptions in DPIAs is an explicit GDPR Art.35 requirement.

AWS KMS Encryption: Necessary But Not Sufficient

DynamoDB tables are encrypted at rest by default using AWS KMS. You can use AWS-managed keys (aws/dynamodb), AWS-owned keys, or customer-managed keys (CMK). Customer-managed keys give you the ability to disable or delete the key, rendering the data inaccessible.

CMK encryption is frequently cited as a CLOUD Act mitigant: "if we control the key, the US government cannot access the data." This argument has three weaknesses in the DynamoDB context:

KMS is also a US-jurisdiction service: AWS KMS is operated by AWS Inc. (Delaware). A CLOUD Act order can compel AWS to use its operational access to KMS to decrypt data on the government's behalf, or to hand over the CMK plaintext material under its control. The government can seek both the data and the key from the same provider.

Operational access during processing: DynamoDB must decrypt data to serve read requests. During normal operation, the plaintext version of items passes through AWS's compute infrastructure. A CLOUD Act order targeting in-flight data or the execution environment during a query bypasses the at-rest encryption.

Backup copies: PITR backups are stored encrypted, but they are encrypted with the same KMS infrastructure. A CLOUD Act order targeting backup objects has the same KMS key access problem.

The Practical GDPR Risk Surface: A Summary

EU-Native Alternatives for DynamoDB Use Cases

The choice of replacement depends on the DynamoDB feature set you actually use. DynamoDB handles two distinct use cases that have different EU-native replacement paths: key-value at scale (gaming, sessions, leaderboards) and document storage (user profiles, product catalogues, content management).

ScyllaDB on Hetzner or OVHcloud

ScyllaDB is a Cassandra-compatible, C++-rewritten wide-column store that achieves DynamoDB-comparable latency at much lower cost. ScyllaDB Inc. is a US company (incorporated in Delaware), but the software is Apache 2.0 licensed and runs on any EU-hosted VM.

EU-sovereign deployment: ScyllaDB deployed on Hetzner Cloud (Munich, Germany — Hetzner Online GmbH, registered in Germany) or OVHcloud (OVH SAS, registered in Roubaix, France) is fully under EU jurisdiction. There is no CLOUD Act exposure for self-managed ScyllaDB on EU-incorporated cloud providers. The only CLOUD Act exposure would be if you use ScyllaDB Cloud (their managed service), which has US data centres.

DynamoDB compatibility: ScyllaDB Alternator provides a DynamoDB-compatible API. You can often migrate DynamoDB workloads to ScyllaDB Alternator with minimal code changes — DynamoDB SDK calls hit the ScyllaDB Alternator endpoint instead.

Performance: ScyllaDB consistently benchmarks at lower P99 latency than DynamoDB for equivalent workloads, particularly for write-heavy use cases. Hetzner CPX41 instances (8 vCPU, 16 GB RAM, €25/month) running a 3-node ScyllaDB cluster provide DynamoDB-comparable performance at a fraction of the cost.

Apache Cassandra on Managed EU Infrastructure

Apache Cassandra is the upstream project that ScyllaDB is compatible with. Cassandra is a pure Apache Software Foundation project with no commercial entity that can be subpoenaed. A 3-node Cassandra cluster on OVHcloud or Scaleway is legally comparable to ScyllaDB on the same infrastructure.

Managed Cassandra: Instaclustr offers managed Cassandra hosted on OVHcloud EU regions. Instaclustr is now part of NetApp (US-incorporated), so you need to evaluate their DPA carefully. Alternatively, use Cassandra's native tooling on Hetzner with a managed-service wrapper.

Couchbase on EU Infrastructure

Couchbase is a document database with a DynamoDB-like JSON document model and a SQL++-based query language. The Couchbase Server software is open source (Apache 2.0). Couchbase, Inc. is US-incorporated, but self-hosted Couchbase on EU infrastructure is EU-sovereign.

Couchbase Capella (their managed cloud offering) runs on AWS, GCP, or Azure — including EU regions — but inherits those providers' CLOUD Act exposure. Self-hosted Couchbase on Hetzner or OVHcloud avoids this.

ArangoDB on EU Infrastructure

ArangoDB is a multi-model database that handles key-value, document, and graph use cases from a single engine. ArangoDB GmbH is incorporated in Cologne, Germany — making it one of the few database vendors with genuine EU legal incorporation. ArangoDB Community Edition is Apache 2.0 licensed.

For DynamoDB replacement use cases, ArangoDB's document model and AQL (ArangoDB Query Language) cover the same semantic ground as DynamoDB's PartiQL. The multi-model approach is useful if your DynamoDB tables contain items with relationships that you model via secondary indexes and adjacent lookups — ArangoDB's graph layer handles these natively.

ArangoDB Cloud (Oasis): ArangoDB's managed service runs on GCP (US-incorporated) and AWS. For EU-sovereign deployments, self-host on Hetzner or use the Hetzner-backed deployments that ArangoDB offers through their EU partnerships.

sota.io: EU-Native PaaS for Your Full Stack

If your DynamoDB workload is part of a larger application stack — an API, a set of background workers, a Streams-to-Lambda pipeline — the jurisdiction problem extends beyond just the database. Every AWS service in your architecture inherits the CLOUD Act exposure.

sota.io runs your full application stack on EU-incorporated, EU-operated infrastructure. Your API workers, your event processors, your caching layer, and your database (PostgreSQL, Redis, or a managed NoSQL engine) all run under a single EU legal jurisdiction. You replace DynamoDB Streams + Lambda with an EU-native event-driven architecture (PostgreSQL logical replication + a sota.io worker, or a Redis Streams-backed consumer group).

The pricing model is significantly different from DynamoDB's on-demand billing. DynamoDB costs scale with request volume — at scale, DynamoDB bills can reach thousands of euros per month for high-write workloads. sota.io starts at €9/month for a complete application stack.

Practical Migration Path from DynamoDB

Step 1: Audit Your Global Tables Configuration

Before any migration work, run this check:

aws dynamodb describe-table \
  --table-name your-table \
  --query 'Table.Replicas[*].RegionName'

Any US region in the output is an active Art.44 GDPR violation. If you find one, the immediate remediation is to remove the US replica and document the incident in your GDPR Art.33 breach register — cross-region replication to the US is a transfer of personal data to a third country without adequate safeguards.

Step 2: Inventory Your Streams Consumers

List all Lambda functions triggered by DynamoDB Streams:

aws lambda list-event-source-mappings \
  --query 'EventSourceMappings[?contains(EventSourceArn, `dynamodb`)].[FunctionName,EventSourceArn]' \
  --output table

Each Lambda in this list is a GDPR processing activity under the CLOUD Act jurisdiction scope. Document them in your Records of Processing Activities (ROPA) under GDPR Art.30.

Step 3: Choose Your Migration Target

Step 4: Migrate PITR Backup Strategy

DynamoDB PITR has no direct open-source equivalent at the same level of seamless integration. Your migration plan should include:

• ScyllaDB: Use nodetool snapshot for point-in-time table snapshots, stored in EU-hosted S3-compatible object storage (Hetzner Object Storage, OVHcloud Object Storage)
• Cassandra: nodetool snapshot with the same EU object storage target
• ArangoDB: arangodump with scheduled backups to EU-hosted storage

Step 5: Replace DAX

DAX has no open-source equivalent (proprietary protocol). When migrating from DynamoDB + DAX to an EU-native stack:

• ScyllaDB Alternator: ScyllaDB handles caching at the storage engine level; a Redis/Valkey sidecar handles application-level caching
• ArangoDB: ArangoDB has an internal in-memory cache; augment with a Redis/Valkey cluster on the same EU infrastructure

DPO Checklist: DynamoDB GDPR Assessment

Before your next DPIA renewal, verify each of these:

1. Global Tables audit: No US regions in any table replica configuration. Verify with describe-table API.
2. Streams retention: Streams are enabled with a documented business justification for the 24h retention window. If no downstream consumer needs the full 24h, consider disabling Streams on tables that do not require CDC.
3. PITR window: 35-day PITR retention aligned with your data retention policies. If your data retention policy is 7 days, PITR at 35 days creates a compliance gap.
4. Export destination: All DynamoDB exports target EU-region S3 buckets. US-region export buckets are an Art.44 transfer.
5. Lambda trigger inventory: All Streams→Lambda triggers documented in ROPA under Art.30.
6. DAX cluster: If DAX is used, it is in the same EU region as the primary table and its data classified in your ROPA.
7. KMS CMK: Customer-managed KMS keys used for tables containing sensitive personal data, with key deletion policy documented.
8. Scoping your DPIA: Your DPIA covers not just the DynamoDB table but the full processing chain — Streams, Lambda triggers, S3 exports, and PITR backups.

Summary

AWS DynamoDB is a capable, scalable managed NoSQL database. It is not a GDPR-compliant data store for EU personal data when the threat model includes CLOUD Act compelled disclosure.

The structural problem is the same as for every AWS service: AWS Inc. (Delaware) holds operational control over your Frankfurt DynamoDB cluster. A CLOUD Act order can compel AWS to disclose your table data, your Streams change records, your PITR backups, and your DAX cache. EU regional data residency does not change this legal fact.

DynamoDB-specific risks beyond the base CLOUD Act issue include:

• Global Tables: Accidental US replica addition = immediate Art.44 violation
• Streams + Lambda pipeline: CLOUD Act jurisdiction extends to your full event-processing chain
• PITR: 35-day historical window of personal data, same jurisdiction
• PartiQL: SQL facade that obscures NoSQL-specific compliance gaps in DPIAs

EU-native alternatives are production-ready in 2026. ScyllaDB Alternator provides a DynamoDB-compatible API on EU-hosted Hetzner infrastructure. ArangoDB (German-incorporated) covers document use cases with native EU legal guarantees. Apache Cassandra on OVHcloud or Scaleway covers wide-column workloads.

If you are building a full application stack and want to avoid CLOUD Act exposure across every layer — database, cache, compute, event processing — sota.io runs your entire stack on EU-native infrastructure starting at €9/month.

Continue the AWS series:

• AWS RDS EU Alternative: GDPR, CLOUD Act, and the Managed Database Jurisdiction Problem
• AWS ElastiCache EU Alternative: GDPR, CLOUD Act, and the Session Data Jurisdiction Problem
• AWS European Sovereign Cloud: What It Is and What It Does Not Fix