AWS Timestream EU Alternative 2026: GDPR, CLOUD Act, and the Behavioral Profiling Problem in Time-Series Data

Post #782 in the sota.io EU Compliance Series

AWS Timestream is Amazon's fully managed time-series database service, optimised for ingesting and querying billions of time-stamped data points at low latency. It is widely used for IoT applications, application performance monitoring, operational metrics, clickstream analysis, and user activity tracking. Timestream's serverless architecture auto-scales ingest capacity, separates recent "memory store" data from historical "magnetic store" data, and integrates natively with AWS IoT Core, Kinesis, Lambda, and Grafana.

Time-series data has a property that many developers do not fully appreciate from a GDPR perspective: it is almost always personal data when it is linked to a user, device, or entity that can be identified. A sequence of timestamped events is, by definition, a behavioral record — and behavioral records are personal data under Art.4(1) GDPR. When your application writes {user_id: 12345, action: "page_view", timestamp: 2026-05-02T09:14:23Z} to Timestream, you have created a personal data record subject to the full GDPR regime.

AWS operates Timestream in Frankfurt (eu-central-1) and other European regions. It ships with the standard AWS GDPR Data Processing Addendum and Standard Contractual Clauses. And like every AWS service, it is operated by Amazon Web Services, Inc., a Delaware-incorporated entity fully subject to the CLOUD Act (18 U.S.C. § 2713), regardless of where the physical data resides.

This post analyses Timestream's specific GDPR exposure, explains why its append-optimised architecture creates structural Art.17 and Art.22 problems, and maps the best EU-native time-series database alternatives for 2026.

What Timestream Does — and Why Time-Series Semantics Complicate GDPR

Timestream stores data as time-ordered records with a mandatory timestamp dimension. Data is written once and queried by time range — the core model is append-optimised, not update-optimised. This makes Timestream extremely efficient for high-throughput ingest but creates a structural tension with GDPR rights that assume data can be corrected or erased on a per-record basis.

Memory store and magnetic store: Timestream separates data by recency. Recent data (configurable, default 6-24 hours) lives in the memory store — in-memory, fast, expensive. Older data is automatically moved to the magnetic store — on SSD, cheaper, slower. Each store has its own retention policy. Deletion is controlled by these retention policies, not by individual record operations. You configure how long data lives at the table level, not the row level.

The append-only ingest model: Timestream does not support UPDATE or DELETE SQL operations on individual records in the way a relational database does. You can delete entire tables, configure retention to purge data after a time window, or use the DeleteTable / DeleteDatabase operations — but you cannot issue DELETE FROM metrics WHERE user_id = '12345' and expect Timestream to remove all records for a specific data subject. Timestream's query engine supports SELECT and Timestream SQL but its DML is strictly append-oriented.

Multi-dimensional records: Timestream records consist of a timestamp, one or more dimensions (string identifiers like user_id, device_id, region), and one or more measures (the actual values). The dimensions are indexed for fast filtering. This structure makes per-user queries extremely efficient — but it also means that every measure ever recorded for a user is durably stored in the magnetic store until the table-level retention period expires.

Scheduled queries and derived tables: Timestream supports scheduled queries that aggregate raw data into derived summary tables. A scheduled query might compute a user's daily active session count and write it to a summary table. This creates derived personal data records that exist independently of the original raw data — an Art.17 request against the raw table does not automatically purge derived tables that were computed from that raw data.

GDPR Art.4(1): When Time-Series Data Becomes Personal Data

The critical threshold question for GDPR compliance is whether your Timestream data is personal data. Under Art.4(1), personal data is "any information relating to an identified or identifiable natural person." The key word is identifiable — the data does not need to directly name the person; it is sufficient if the data can be combined with other information available to the controller to identify an individual.

User activity tracking: If you store user_id (even a pseudonymous UUID) as a dimension in Timestream, and your application can map that UUID to an identified user (via a users table in RDS, DynamoDB, or another database), the Timestream data is personal data. Every page view, API call, feature usage event, and session timestamp is part of a behavioral record about an identifiable person.

IoT device data: Device-level telemetry — temperature sensor readings, motion detector events, vehicle GPS traces, smart meter energy consumption — is personal data when the device is linked to a household or individual. Art.4(1)'s "singling out" criterion applies: even without a name, a sequence of GPS coordinates recorded at regular intervals constitutes personal data because it can be used to infer home address, workplace, routine, and social connections.

Health and biometric metrics (Art.9): Wearable device data — heart rate, blood oxygen, sleep stages, step counts, stress indicators — is health data under Art.9 GDPR. Art.9 processing is prohibited unless explicit conditions (Art.9(2)) are met. Storing health time-series in Timestream without a specific Art.9(2) legal basis is unlawful, not merely non-compliant. The fact that the data is stored as numeric measures with a device_id dimension rather than a "medical record" does not reduce its classification.

Application performance monitoring with user context: Many APM implementations write request traces that include user_id, session_id, or IP address dimensions. This is personal data. Developers frequently treat APM data as "operational" rather than personal, but GDPR does not recognise this category distinction. If the trace record can be linked to an individual, it is personal data.

GDPR Art.17: The Right to Erasure vs. the Append-Only Model

Article 17 GDPR requires that personal data be erased "without undue delay" on request when specified conditions are met. The practical question for Timestream is: what does "erasure" mean in an append-only time-series database?

No per-record delete: Timestream does not provide a SQL DELETE statement that removes individual rows matching a predicate. The absence of per-record deletion is not a bug or an oversight — it is fundamental to Timestream's performance model. Append-only writes to columnar storage optimised for time-range scans cannot efficiently support random-access deletes.

Table-level retention as the only erasure mechanism: The supported erasure mechanism in Timestream is retention policy configuration. You set a memory store retention period (hours) and a magnetic store retention period (days). When data ages past the retention window, Timestream deletes it automatically. This is not Art.17 erasure — it is scheduled batch deletion based on data age, not on the identity of the data subject. An Art.17 request received the day after data ingestion cannot be fulfilled by telling the data subject "your data will be automatically deleted in 365 days."

The "without undue delay" requirement: EDPB guidelines on Art.17 specify that erasure should occur within one month of the request (with a possible extension to three months for complex cases). Retention-based deletion cannot satisfy this timeline unless the retention period happens to expire within the same window — which defeats the purpose of using a time-series database for historical analysis.

Derived table contamination: As noted above, scheduled queries create derived summary tables. These tables may contain aggregated metrics that are personal data (e.g., "user 12345 had 47 page views yesterday"). Even if the raw data is purged, the derived record persists. A complete Art.17 response requires identifying and purging all derived tables that contain personal data about the subject.

Practical compliance paths: Organisations using Timestream for personal data face a difficult choice. The most common approach is to avoid using directly identifying dimensions (user_id, email, IP) and instead use a secondary pseudonymous identifier that maps to real user identity via a separate lookup table. Art.17 compliance then consists of deleting the pseudonymous identifier from the lookup table — breaking the link between the time-series data and the identified person. This satisfies Art.17 if the pseudonymous ID cannot be re-identified without the lookup table, and if no other identifying information exists in the time-series dimensions or measures. This architecture requires deliberate design; it is not Timestream's default.

GDPR Art.22: Behavioral Profiling and Automated Decision-Making

Article 22 GDPR grants data subjects the right not to be subject to decisions based solely on automated processing — including profiling — that produce legal or similarly significant effects. Art.22(1) is not limited to formal "decision systems"; it applies when automated processing is the primary or exclusive basis for a consequential outcome.

Time-series data is the raw material for behavioral profiling at scale. The specific Art.22 risks in Timestream implementations:

Clickstream-based segmentation: User activity time-series (page views, feature usage, session durations) are frequently used to train ML models that segment users into behavioural categories — "high-value," "churn risk," "enterprise prospect." When these segments drive automated pricing, access restrictions, or service tier decisions, Art.22 requirements apply. Timestream's Grafana integration and scheduled query capabilities facilitate exactly this kind of automated pipeline.

Anomaly detection with automated consequences: Timestream is commonly used for security and operational monitoring. Anomaly detection on user activity time-series — unusual login times, atypical transaction volumes, geographic outliers — can trigger automated account freezes, payment holds, or access restrictions. If the decision is made purely by the anomaly detection algorithm without human review, Art.22(3)'s right to human intervention, to express one's point of view, and to contest the decision is implicated.

IoT-based behavioural inference: Insurance telematics (driving behaviour scoring), smart building occupancy tracking, and employee productivity monitoring via device telemetry are all Art.22 use cases. The time-series database is the engine; the decision logic sits downstream. But GDPR's accountability principle (Art.5(2)) means the data controller must be able to demonstrate the legal basis for automated profiling at every stage of the pipeline — including the data storage layer.

Art.35 DPIA obligation: Art.35 requires a Data Protection Impact Assessment before processing that is "likely to result in a high risk to the rights and freedoms of natural persons." Systematic monitoring of individuals' behaviour, large-scale processing of special category data, and automated decision-making with legal effects each independently trigger the Art.35 obligation. An organisation using Timestream for large-scale IoT health data, clickstream profiling, or automated fraud detection almost certainly requires a DPIA.

CLOUD Act: Jurisdiction Over Every Data Point

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713) requires US-incorporated companies to produce data stored anywhere in the world in response to valid US government orders. Amazon Web Services, Inc. is incorporated in Delaware. It is fully subject to the CLOUD Act regardless of whether your Timestream database is deployed in Frankfurt (eu-central-1) or any other European region.

For Timestream specifically:

The magnetic store is stored data: CLOUD Act scope covers "stored wire or electronic communications" and related records. Timestream's magnetic store — durable, on-disk, persistent — is unambiguously within CLOUD Act scope. A valid US government order directed at Amazon could compel production of Timestream tables, including the complete historical behavioral record of every data subject in those tables.

IoT health data and law enforcement interest: For organisations storing health-related IoT data in Timestream, the CLOUD Act intersection is particularly sensitive. Law enforcement requests for health time-series — drug usage patterns inferred from biometric data, mental health indicators, reproductive health events — are a documented concern following the Dobbs ruling in the US and increased health-data law enforcement activity in other jurisdictions. Storing EU health data in AWS services subject to US jurisdiction creates a direct conflict with Art.9's strict processing conditions.

GDPR Art.48 conflict: Disclosing Timestream data to US authorities under CLOUD Act without an EU-recognised international legal framework (MLAT or equivalent) constitutes a potential Art.48 GDPR violation. The European Data Protection Board has consistently taken the position that CLOUD Act orders do not provide a valid GDPR Art.48 basis. The practical result is that a disclosure compelled by US law may simultaneously violate EU law — a conflict that falls on the data controller (your organisation), not AWS.

EU-Native Time-Series Database Alternatives

The following alternatives are either fully open-source (self-hostable on EU infrastructure) or offered by EU-incorporated providers with EU-only data storage.

InfluxDB (InfluxData)

The original purpose-built time-series database. InfluxDB v3 (Apache Arrow/Parquet-based) offers massive improvements over v1/v2 in query performance and storage efficiency. Self-hosted on EU infrastructure, InfluxDB gives you complete control over data residency and erasure. The open-source edition supports DELETE FROM with a time range predicate — not full row-level delete, but sufficient for most retention-based GDPR approaches. Aiven for InfluxDB is available in EU regions (Frankfurt, Amsterdam) through Aiven Ltd (Finnish-incorporated), providing a managed option with EU data residency and GDPR DPA.

TimescaleDB (Timescale)

TimescaleDB extends PostgreSQL with native time-series optimisations: automatic partitioning by time (hypertables), compressed chunk storage, continuous aggregates, and time-bucketed queries. Because it is built on PostgreSQL, TimescaleDB fully supports DELETE and UPDATE SQL — including DELETE FROM metrics WHERE user_id = $1, which makes Art.17 compliance straightforward. Timescale Cloud is available in AWS eu-central-1 (Frankfurt), but the company is US-incorporated (New York). Self-hosted TimescaleDB on EU infrastructure (Hetzner, OVHcloud, Scaleway) provides full EU sovereignty. The PostgreSQL foundation also means that existing GDPR compliance tooling (row-level security, audit triggers, logical replication) works natively.

QuestDB

QuestDB is a high-performance time-series database with a SQL interface, built in Java, open-source (Apache 2.0). It supports extremely high ingest rates (4+ million rows/second) with a column-oriented storage format optimised for time-range queries. QuestDB supports UPDATE and DELETE SQL as of version 7.x, providing viable Art.17 compliance paths. Self-hosted deployment on EU infrastructure puts data residency fully in your control. QuestDB Cloud is available on AWS eu-west-1 (Ireland) — not Frankfurt, and AWS-hosted so CLOUD Act still applies. For EU sovereignty, self-hosted is the correct deployment mode.

VictoriaMetrics

VictoriaMetrics is a Prometheus-compatible time-series database and monitoring solution, widely used as a Prometheus long-term storage replacement. It supports significantly higher cardinality and better compression than Prometheus. The enterprise edition adds multi-tenancy, LDAP, and cluster management. Self-hosted on EU infrastructure, VictoriaMetrics stores data in local files under your control. It supports time-range data deletion via the /api/v1/admin/tsdb/delete_series HTTP API endpoint — adequate for Art.17 compliance in metrics use cases. The company (VictoriaMetrics Ltd) is UK-incorporated; post-Brexit UK is not EU, so EU-sovereignty deployments should be self-hosted on EU cloud.

Grafana Mimir (Grafana Labs)

Grafana Mimir is the open-source horizontally scalable Prometheus-compatible time-series storage backend. Grafana Labs (Swedish founders, US-incorporated) offers Grafana Cloud with EU data residency in Frankfurt. Self-hosted Mimir on EU infrastructure provides full sovereignty. Mimir is designed for very high ingest rates and long-term metrics storage, with tenant isolation and tenant-scoped data deletion APIs that facilitate GDPR compliance in multi-tenant architectures.

sota.io Platform

For development teams that want to deploy time-series infrastructure without managing cloud provider data processing agreements, the sota.io platform provides EU-native managed hosting (Frankfurt) with data residency guarantees, no US parent company, and GDPR DPAs under EU law. Deploy InfluxDB, TimescaleDB, or VictoriaMetrics on sota.io infrastructure and inherit EU-sovereign hosting from the platform layer up — without negotiating separate DPAs with US hyperscalers.

Architecture Guidance: Making Time-Series GDPR-Compliant

Pseudonymisation by design

The most practical approach for GDPR-compliant time-series storage is strict pseudonymisation at the dimension level. Do not write user_id: "user@example.com" or user_id: 12345 (if 12345 maps directly to an identified user in your primary database). Instead, write a pseudonymous token — a UUID or hash — that has no meaning without the mapping table. Store the pseudonymous-to-real mapping separately, outside the time-series database, with strict access controls.

Art.17 erasure then becomes: delete the mapping record. The time-series data remains but is effectively anonymised — no longer personal data — once the link is severed. This architecture requires that the pseudonymous ID cannot be re-identified through any other dimension or measure in the time-series data (e.g., GPS coordinates that uniquely identify a person even without an explicit ID field).

Retention policy alignment with GDPR

Configure time-series retention policies to match the lawful processing period for each data category. Health data (Art.9) typically requires stricter limits than operational metrics. Separate tables (or table-level retention configurations) for different data categories allow granular retention management. Do not default to maximum retention because storage is cheap — document the specific retention period and its legal basis in your Records of Processing Activities (RoPA) under Art.30.

Separate special category data

Art.9 health, biometric, and other special category data should be stored in separate tables (or databases) with explicit processing documentation, enhanced access controls, and DPIA coverage. Do not co-mingle Art.9 data with operational metrics in the same table — this complicates access controls, retention management, and audit trails.

DPIA before deployment

Before deploying time-series infrastructure for user behaviour tracking, IoT health data, or automated decision pipelines, complete a DPIA under Art.35. The DPIA should address: categories of personal data stored, data subject rights mechanisms (especially Art.17 erasure paths), CLOUD Act jurisdiction risk, processor relationships (time-series database vendor), automated decision-making safeguards (Art.22), and data retention justification.

Conclusion

AWS Timestream provides compelling performance and serverless scalability for time-series workloads — but its append-only architecture, absence of per-record deletion, and CLOUD Act jurisdiction exposure create structural compliance gaps for GDPR-regulated personal data.

The key risks are:

1. Art.17 erasure gap: No DELETE WHERE user_id = X — erasure requires retention-policy deletion (table-level, time-based) or pseudonymisation architecture that severs the identifying link.
2. Art.22 behavioral profiling: Time-series is the natural substrate for automated behavioral scoring; automated decision-making pipelines built on Timestream require explicit Art.22 compliance documentation.
3. Art.9 health data exposure: IoT health metrics stored in Timestream are subject to Art.9's strict processing conditions and CLOUD Act jurisdiction.
4. CLOUD Act jurisdiction: All Timestream data — including historical behavioral records — is accessible to US government under CLOUD Act regardless of EU region deployment.

EU alternatives — InfluxDB (self-hosted), TimescaleDB (PostgreSQL-native deletes), QuestDB, VictoriaMetrics — eliminate the CLOUD Act exposure and provide explicit deletion APIs that support Art.17 compliance. Deploying these alternatives on EU-native infrastructure such as sota.io closes the jurisdiction gap at the hosting layer.

Choose Timestream for analytics workloads with no personal data — infrastructure metrics, aggregate operational telemetry, non-linked IoT data. Choose EU-native time-series infrastructure for any data linked to identifiable individuals.