AWS Timestream in 2026: Time-Series Databases, Keyspaces and Architecture Choices

Last updated: October 23, 2026.

If you are choosing AWS Timestream for a new IoT or observability workload today, the first fact to absorb is not a feature but a status: AWS closed Timestream for LiveAnalytics to new customers effective June 20, 2025, and now points new projects at Timestream for InfluxDB. Half of the architecture advice still circulating, including an earlier version of this article, was written for a world in which LiveAnalytics was the default answer. It is not the default any more, and a design that assumes it will fail an architecture review on day one.

This guide rebuilds the decision from scratch for October 2026. It separates the three things people call “Timestream”, explains what InfluxDB 3 changed, shows where Amazon Keyspaces genuinely fits (and where it quietly does not), and ends with a reference ingestion architecture using the native AWS IoT Core InfluxDB rule action that shipped in August 2026. You will leave with a decision tree, a cost model you can adapt, and a list of failure modes to test before production.

What this covers: the 2026 status of every AWS time-series option, the architecture of Timestream for InfluxDB 2 and 3, Keyspaces data modelling for telemetry, an IoT Core to dashboard reference design, a LiveAnalytics migration path, a decision matrix, failure modes and a practical checklist.

Context and Background

“Time series” is a workload shape, not a product category. Points arrive in timestamp order, are almost never updated, are queried by time range plus a handful of identifying attributes, and lose value as they age. Every AWS option below is a different bet on which of those properties to optimise: ingest rate, query flexibility, storage cost or operational simplicity.

For years the AWS answer was Amazon Timestream, launched as a serverless database with two storage tiers. In March 2024 AWS shipped a second engine under the same brand, Timestream for InfluxDB, which went generally available on March 14, 2024 according to the Timestream document history. The original product was renamed Timestream for LiveAnalytics to distinguish the two. They share a name, a console section and a billing line item. They do not share an engine, a data model or a query language.

Then the ground moved twice. On May 20, 2025 AWS announced that LiveAnalytics would stop accepting new customers from June 20, 2025. On October 16, 2025 it announced that Timestream for InfluxDB supports InfluxDB 3 in two editions, Core and Enterprise. In March 2026 the Enterprise edition grew to clusters of up to 15 nodes. By August 2026 AWS IoT Core could write to InfluxDB directly from the rules engine. The practical consequence is that the “serverless TSDB with SQL” box on the AWS menu is now occupied by a managed InfluxDB, and the interesting engineering questions have shifted accordingly.

This article assumes you already know the vocabulary of series, tags and retention. If you want the storage-engine internals behind these products, our comparison of InfluxDB, Timescale and QuestDB internals covers LSM trees, columnar chunks and compression in depth. For the plant-floor angle, the industrial IoT time-series platform architecture post shows where a TSDB sits between historian and analytics.

The three things called “Timestream”

It helps to name them separately, because most confusion in AWS forums comes from conflating them.

Timestream for LiveAnalytics is the original serverless engine: databases and tables, a memory store and a magnetic store, schemaless writes through the WriteRecords API, a SQL dialect, and compute metered in Timestream Compute Units. It still runs for existing customers and AWS says it continues to invest in security, availability and performance. It is, in effect, a maintained but closed product.

Timestream for InfluxDB 2 is managed open-source InfluxDB 2.x running on instances you size yourself, in single-instance or Multi-AZ form. Existing InfluxDB 2.x applications and tools work without change, and you query with Flux or InfluxQL.

Timestream for InfluxDB 3 is managed InfluxDB 3, an engine rebuilt on Apache Arrow, Apache DataFusion and Parquet, with data persisted in Amazon S3. It speaks SQL and InfluxQL, and it is the target AWS’s migration guide recommends for most LiveAnalytics workloads.

Alongside these sit the general-purpose options teams have always used for telemetry: Amazon Keyspaces, Aurora PostgreSQL, OpenSearch, and an S3 data lake queried by Athena. Section by section, we will place each one.

The 2026 Decision Framework: Pick by Access Pattern, Not by Brand

The shortest accurate answer: for a new AWS workload that needs a managed time-series database with SQL, choose Timestream for InfluxDB 3; choose InfluxDB 2 only for small, low-latency operational estates; choose Keyspaces when queries are always “this device, this time window”; and choose S3 plus Iceberg plus Athena when latency in seconds is acceptable and cost per terabyte dominates.

Figure 1: Decision tree for AWS time-series workloads in 2026. The first branch is whether you already hold a LiveAnalytics account, because new accounts cannot create one.

The tree in Figure 1 asks one question first (do you already run LiveAnalytics?) and then routes by the dominant access pattern. Four categories cover almost every telemetry system.

Branch 1: existing LiveAnalytics customers

If you already have an active payer account using the service, nothing breaks. The AWS availability notice states that the change “will not impact customer workloads” and that existing customers with an active payer account can keep adding users and linked accounts. That is a statement about access, not a roadmap commitment, and a prudent team reads it as: you have time, but every new table you create deepens the migration debt. A sensible policy is to freeze new workloads onto InfluxDB 3 while leaving stable LiveAnalytics tables alone until a migration is funded.

Branch 2: ad hoc SQL, dashboards and wide analytics

This is InfluxDB 3 territory. Because storage is Parquet in object storage, the engine separates compute from data, is designed for very high series cardinality rather than the in-memory index limits of the 2.x line, and answers analytical SQL over long windows. The same files can in principle be read by other Parquet-aware engines, which matters for exit strategy. We examine the architecture in the next section.

Branch 3: key-based lookups at scale

If every query is “give me device X for hour Y” and you expect billions of rows with predictable latency, a wide-column store is a legitimate fit. Keyspaces is Cassandra-compatible, serverless and priced per request. It will not compute a rolling average for you, which is the price of its predictability.

Branch 4: batch analytics and machine learning

When the consumer is a training job, a regulatory report or a weekly KPI rollup, the cheapest design is Parquet files in S3 under an Iceberg table, queried with Athena. You give up sub-second dashboards and get close to the lowest storage cost AWS offers. Our Iceberg v3 specification walkthrough explains why the table format matters for late-arriving sensor data.

A fifth, honest branch: relational plus time

If your telemetry is a small fraction of a relational model, say a few thousand devices with joins against asset hierarchies, Aurora PostgreSQL with native range partitioning may beat a dedicated TSDB on total complexity. Our Postgres 18 versus TimescaleDB versus ClickHouse comparison gives numbers on where that stops being true.

Timestream for InfluxDB: What You Actually Get on AWS

Timestream for InfluxDB is a managed deployment of InfluxDB, not a re-implementation. AWS provisions the instances or nodes, wires them into your VPC, handles patching and failover, and exposes the normal InfluxDB HTTP API. That has one big advantage (your existing tooling, Telegraf agents and client libraries work) and one big limitation (the scaling model is InfluxDB’s, not an AWS-native serverless one). The version you pick determines almost everything else.

InfluxDB 2: instance-based and cardinality-bound

The 2.x offering runs on db.influx memory-optimised instance classes, from db.influx.medium (1 vCPU, 8 GiB) up to db.influx.24xlarge (96 vCPU, 768 GiB) per the service documentation. You choose between a single instance, suitable for development and test, and a Multi-AZ deployment with a primary and a standby in another Availability Zone. Storage is a provisioned volume with included IOPS, up to 16 TiB per instance, and AWS caps an account at 40 instances.

The design guidance in that same page is revealing, because it tells you where the engine’s ceiling sits. Keep series cardinality under 10 million per instance. Sort tags by key before writing. Batch 5,000 lines of line protocol per request, and enable gzip, which AWS says can speed writes by up to 5x. A sizing example from the documentation maps roughly 50,000 lines per second with fewer than 100,000 series to db.influx.large, and roughly 750,000 lines per second with fewer than 10 million series to db.influx.12xlarge.

Those are sizing hints, not benchmarks, and your point size, tag layout and query mix will move them. They are still useful because they show the shape of the trade-off: InfluxDB 2 is a single-writer engine where cardinality is paid for in memory, so you scale it by buying a bigger instance. For a plant with a few hundred thousand series and operational dashboards that need single-digit millisecond answers, that is a perfectly good bargain. For a fleet with per-device, per-sensor, per-firmware-version tags it eventually is not.

InfluxDB 3: Arrow, DataFusion, Parquet and S3

InfluxDB 3 replaces the storage and query core. Incoming points are buffered in memory and written to a write-ahead log for durability, then persisted as Parquet files in object storage. Queries run on Apache DataFusion over Arrow memory, with predicate pushdown into Parquet row groups. This family of components is sometimes called the FDAP stack (Flight, DataFusion, Arrow, Parquet). AWS describes the 3.x offering as built on Arrow, DataFusion and Parquet “with data persisted in Amazon S3”, and claims “virtually unlimited storage capacity”.

Figure 2: Reference ingestion architecture. IoT Core rules write to Timestream for InfluxDB 3 for hot queries and in parallel land Parquet in S3 for the lake, with an error action capturing rejected payloads.

Two editions exist. Core is the open-source edition, aimed at near-real-time workloads that mostly touch recent data, and runs as a single node. Enterprise adds high availability, compaction for long-term storage and multi-node operation. When it launched in October 2025 Enterprise supported up to three nodes. On March 16, 2026 AWS announced clusters of up to 15 nodes: one to four writer/reader nodes, zero to thirteen reader-only nodes, and exactly one dedicated compactor node, spread across Availability Zones, with nodes addable and removable and an upgrade path from Core.

The role split is the architectural point. Ingestion, query serving and compaction are different workloads with different resource profiles: ingestion is latency-sensitive and memory-hungry, queries are bursty and CPU-bound, and compaction is a heavy background rewrite of Parquet. Separating them lets a dashboard storm hammer the reader nodes without stalling writers. The cost is that you now size and pay for three roles, and a single compactor is a component whose lag you should alert on.

Pricing mechanics you can model

AWS publishes the model even where it does not publish every number. For InfluxDB 2 and the instance-based flavour, you pay per DB instance-hour and per GB-month of storage, billed per second with a 10-minute minimum after a status change, and Multi-AZ doubles the instance charge because the standby is billed. The pricing page gives example rates such as $0.956 per hour for a db.influx.2xlarge in single-AZ form and $1.913 in Multi-AZ, and storage from $0.10 per GB-month for the 3K-IOPS tier. The page does not state a region for those examples, so treat them as indicative and check your region in the calculator.

For InfluxDB 3, the page says compute is billed per node instance-hour with every node charged equally, and storage per GB-month on shared S3-based storage. It lists no rates for InfluxDB 3 at the time of writing, so any specific InfluxDB 3 dollar figure you see elsewhere is something to verify. What you can reason about is the structure: cost scales with node count and with stored bytes, not with request count or query bytes scanned.

A back-of-envelope example, with illustrative numbers only: suppose a three-node Enterprise cluster costs N dollars per node-hour. Doubling the reader count to absorb dashboards adds 2N per hour, regardless of how many queries run. That is attractive when load is steady and punishing when it is spiky, because you pay for idle readers. LiveAnalytics inverted this: you paid per query compute and per write, which is kind to spiky load and brutal to chatty dashboards.

What the native IoT Core integration changes

On August 25, 2026 AWS announced an InfluxDB rule action for AWS IoT Core. It converts device JSON to line protocol and writes straight to a managed Timestream for InfluxDB database or a self-hosted InfluxDB, with no intermediate Lambda or stream. The developer guide shows it supports both InfluxDB V2 and V3 destinations.

The details matter more than the headline. The payload must be JSON with a case-sensitive timestamp key as an integer epoch; aliases such as ts or time are rejected, and IoT Core does not generate timestamps for you. Tags come from the action’s tags map, which supports substitution templates such as ${clientid()}; remaining payload attributes become fields. The endpoint must be HTTPS on port 443, 8086, 8181 or 8443, and credentials live in Secrets Manager.

Server-side batching is configurable: up to 500 points, a batch window of 5 to 1,000 ms, and up to 131,072 bytes per batch, with batchAcrossTopics off by default. Two operational facts deserve underlining. Batching may reorder points, which is harmless because InfluxDB places data by timestamp. And a single invalid point, for example a field type conflict, fails the whole batch write, because InfluxDB does not partially commit. Billing is metered on outbound payload size in 5 KiB increments, and conversion failures are metered too.

{
  "influxDB": {
    "destinationArn": "arn:aws:iot:us-west-2:111122223333:ruledestination/influxdb/EXAMPLE",
    "roleArn": "arn:aws:iam::111122223333:role/iot-influxdb-role",
    "databaseName": "plant_telemetry",
    "tableName": "machine_metrics",
    "tags": { "device_id": "${clientid()}", "site": "${topic(2)}" },
    "timestampUnit": "ms",
    "batchConfig": { "maxBatchSize": 200, "maxBatchOpenMs": 500, "maxBatchSizeBytes": 65536, "batchAcrossTopics": false }
  }
}

The sample above follows the documented action schema with placeholder ARNs. For V2 destinations you additionally supply the organization. Pair this action with an InfluxDB error action so rejected payloads land in a table rather than disappearing; the error payload carries the rule name, topic, trace identifier and the base64 original message.

Timestream for LiveAnalytics: Understanding What You May Already Run

Plenty of production systems still run on LiveAnalytics, and anyone inheriting one needs to understand it accurately, including the parts that earlier write-ups, including ours, got wrong. LiveAnalytics is a serverless engine with two stores, and the retention policy you set per table moves data between them.

Memory store, magnetic store and the retention window

New records are written to the memory store, which is optimised for fast point-in-time and recent-range queries. When a record ages beyond the table’s memory retention it moves to the magnetic store, which is optimised for large analytical scans. The documented quotas say memory retention ranges from 1 hour to 8,766 hours (about a year) with a default of 6 hours, and magnetic retention from 1 day to 73,000 days. Retention is also the write boundary: data older than the memory window is rejected unless you enable magnetic store writes, and data more than 15 minutes in the future is rejected by default.

That behaviour is the root of the most common production surprise. A gateway that buffers for several hours during an outage and then replays will have its oldest records refused. The fix is either a longer memory window (costly) or magnetic store writes for late data. If your edge uses store-and-forward, which most industrial sites do, read our MQTT store-and-forward guide before sizing retention.

Limits that shape the data model

The quotas page lists the constraints that bite in design reviews. A WriteRecords request carries at most 100 records. A record is at most 2 KB. A table supports 128 dimensions and 8,192 measure names, and a multi-measure record holds up to 256 measures. A query string may be 256 KiB, a query times out after one hour, and a result set is capped at 5 GB. Accounts may have 500 databases and 50,000 tables.

Notice the 100-record batch limit. At one KiB per record, that is a ceiling of about 100 KiB per call, so reaching hundreds of thousands of points per second means many concurrent writers, which is why client-side batching and connection reuse were mandatory in LiveAnalytics designs. Compare that with the 500-point server-side batches in the IoT InfluxDB action and 5,000-line Telegraf batches for InfluxDB 2.

Pricing: why dashboards drove bills

The pricing page lists LiveAnalytics at $0.50 per million 1 KiB writes, $0.036 per GB-hour for the memory store (about $26 per GB-month), $0.03 per GB-month for magnetic store with a 100 GB minimum per account per region, and $0.518 per TCU-hour for queries, where each TCU is 4 vCPU and 16 GB RAM. These are figures for the unnamed region on that page; verify yours.

Two corrections to common folklore follow from these numbers. First, memory store is priced per GB-hour, which works out to roughly 870 times the per-GB-month cost of magnetic at 720 hours a month, so retention windows are a cost lever, not a durability setting. Second, queries are billed as compute time, so a dashboard that refreshes every ten seconds across many panels creates a standing TCU bill even when no one is looking. I could not find a published figure for how much teams save by leaving this model, so measure your own TCU-hours before assuming a number.

Amazon Keyspaces for Telemetry: Where It Fits and Where It Does Not

Amazon Keyspaces is a serverless, Apache Cassandra-compatible wide-column database. It is not a time-series database, but a time-series access pattern is one of the best-understood Cassandra workloads, which is why teams reach for it. The honest framing is: Keyspaces is a very good store for time-ordered rows you will read by key, and a poor engine for anything that needs to compute across keys.

Data modelling: bucketed partitions

In Cassandra-style stores, the partition key decides where data lives and the clustering key decides order within a partition. Telemetry modelling therefore revolves around one question: how many rows should share a partition? A partition keyed only by device_id grows without bound, and one device’s lifetime of readings piles into a single partition. The standard answer is to add a time bucket to the partition key so partitions have bounded size.

Figure 3: Bucketed telemetry partitions in Keyspaces. The bucket is derived from the timestamp at write time, and each query reads one partition in clustering order.

CREATE TABLE telemetry.readings (
  device_id   text,
  day_bucket  date,
  ts          timestamp,
  metric      text,
  value       double,
  PRIMARY KEY ((device_id, day_bucket), ts, metric)
) WITH CLUSTERING ORDER BY (ts DESC, metric ASC)
  AND default_time_to_live = 7776000;  -- 90 days

Choosing the bucket size is arithmetic you should do on paper. If a device emits one reading per second per metric across ten metrics, a day bucket holds 864,000 rows; at roughly 100 bytes each, that is on the order of 86 MB per partition, which is large but tolerable on Cassandra. At ten readings per second per device, move to hour buckets. This arithmetic is illustrative, since row size depends on your schema. Keyspaces enforces a 1 MB maximum row size and a 2,048-byte partition key limit, and does not document a hard partition size cap, but the sizing discipline remains.

What the service guarantees and what it caps

Keyspaces measures throughput in request units. One write request unit covers up to 1 KB per row with LOCAL_QUORUM consistency, and one read request unit covers 4 KB, with LOCAL_ONE reads billed at half. The quotas page lists 40,000 read and 40,000 write units per table per Region by default, 80,000 per account for provisioned capacity, and 3,000 CQL queries per client TCP connection per second. Quotas can generally be raised, but design for the default.

Two numbers in that table decide telemetry designs. First, 40,000 write units per second per table is 40,000 rows of 1 KB or less per second, per table; a fleet pushing past that must shard across tables or request an increase. Second, an unlogged batch is limited to 30 statements, so ingestion needs many concurrent single-partition writes rather than large batches. Both argue for a streaming writer with partition-aware grouping, such as a Lambda consuming from Kinesis or MSK.

Cost and TTL

On November 14, 2024 AWS cut Keyspaces prices: up to 56% lower on-demand single-Region, up to 65% on-demand multi-Region, up to 13% lower provisioned single-Region and 20% multi-Region, and 75% lower TTL delete prices. The pricing page lists only unit definitions and points to a calculator rather than rates, so I will not quote a per-million figure here. The TTL change matters for telemetry specifically, because expiry is how a Cassandra-shaped table implements retention, and TTL deletes are billed per KB of data per row.

The missing analytics layer

Keyspaces gives you rows by key. It will not give you “average temperature across all pumps in building A last week” without scanning many partitions, and cross-partition scans are slow and expensive in any Cassandra-compatible store. Production designs therefore pair Keyspaces with a second system: a stream to S3 and Athena for batch analytics, or a rollup job writing hourly aggregates into a second Keyspaces table. If you find yourself building a rollup framework around Keyspaces, you have re-implemented a time-series database badly, and that is the signal to reconsider InfluxDB 3.

Where Keyspaces earns its place: device-centric products where an end-user app shows “my device’s last 24 hours”, where the access pattern is rigidly key-based, the fleet is large, and the team already operates Cassandra and wants the operations removed. It is also a sound target when you need multi-Region replication, which Keyspaces supports and the InfluxDB offerings, as documented, do not describe.

Reference Architecture: From Device to Dashboard on AWS

With the building blocks clear, here is an end-to-end design built on the services as they exist in October 2026. It is deliberately a dual-path design: one hot path for recent data and dashboards, one cold path for the lake.

The hot path

Devices publish MQTT to AWS IoT Core. A topic rule selects from devices/+/telemetry, and the InfluxDB action writes batches to Timestream for InfluxDB 3 using server-side batching. Grafana, either Amazon Managed Grafana or your own, queries the cluster with SQL. Use reader-only nodes if you are on Enterprise so dashboards cannot starve ingestion.

Treat the payload contract as part of the architecture. Devices must send a numeric timestamp in a unit you fix on the action, ideally epoch milliseconds produced at the sensor or gateway rather than at arrival. Device-generated timestamps are what make late and replayed data land in the correct place. Establish a schema registry discipline early; our post on data contracts and schema evolution for streaming lakehouses applies directly, because a single field changing type from integer to float fails an entire batch.

The cold path

In parallel, a second rule action sends the same messages to Amazon Data Firehose, which writes Parquet to S3 partitioned by date, optionally into an Iceberg table. Athena queries the lake for months of history, ML feature pipelines and audits. This duplicates storage, but it decouples retention policy: the TSDB holds weeks, the lake holds years, and neither is on the critical path of the other.

Where Grafana, Telegraf and MQTT fit

Not every device speaks AWS-flavoured MQTT. Gateways running Telegraf can write line protocol directly to InfluxDB over HTTPS, using the documented 5,000-line batches and gzip. For industrial sources, bring OPC UA data into the same model through a gateway; our OPC UA historian to digital-twin ingestion walkthrough covers the mapping.

Sizing the whole path

A worked, illustrative example. A plant has 2,000 machines with 20 numeric signals each, sampled every second: 40,000 points per second. At roughly 100 bytes per point on the wire, that is about 4 MB/s, or around 345 GB per day before compression. Server-side batching of 200 points turns 40,000 messages-per-second of writes into 200 batched writes per second. IoT Core meters outbound InfluxDB payload in 5 KiB increments, so a 200-point batch of about 20 KB costs four increments, which is far cheaper than 200 separate sub-increment writes each rounded up. These numbers are illustrative; measure your real payload size, because per-message rounding is the hidden cost driver.

If those same 40,000 points per second go to Keyspaces at about 100 bytes each, each row consumes one write unit, so 40,000 units per second sits exactly at the default per-table quota. That arithmetic alone explains why high-rate sensor fleets on Keyspaces usually pre-aggregate at the edge or shard writes across tables.

Migrating Off LiveAnalytics Without Losing a Quarter

The AWS migration guide offers three targets: Timestream for InfluxDB 3 (recommended for most workloads), InfluxDB 2 (for low-latency operational workloads) and Aurora or RDS PostgreSQL (for non-time-series use cases). Every path goes through Amazon S3 as an intermediate layer: export from LiveAnalytics to S3, then load into the target. The overview page does not detail data-model or query differences, so the rest of this section is my engineering reading of the problem and should be validated against the linked sub-guides.

Figure 4: A low-risk migration sequence. Dual-writing from the IoT rules engine lets history backfill and live traffic converge before dashboards are cut over.

Step 1: map the data model

LiveAnalytics stores records as dimensions (the identifying attributes), a measure name and measure values, either single-measure or multi-measure. InfluxDB stores points as a measurement, tags (indexed identifying attributes) and fields (values). The natural mapping sends dimensions to tags and measure values to fields, with the table becoming the measurement. The decision that needs thought is multi-measure records: a record carrying temperature, pressure and vibration maps neatly to one point with three fields, while single-measure records with a measure_name column are often better pivoted into fields than kept as a tag.

The classic trap is mapping a high-churn identifier to a tag. In LiveAnalytics a dimension like session_id was merely a column. In InfluxDB 2 it multiplies series cardinality, which the AWS guidance says should stay below 10 million per instance. InfluxDB 3 is more forgiving here, but unique values in tags still inflate indexes and slow queries. Put unique per-message identifiers in fields, not tags.

Step 2: export, load and dual-write

Export history to S3 as Parquet, transform to line protocol or the load format your chosen InfluxDB target accepts, and bulk-load in time order, oldest first, in batches. In parallel, add the InfluxDB rule action alongside your existing Timestream action so new data lands in both systems. Because IoT Core’s action requires a device-supplied timestamp, verify that your payloads include one before you rely on this; devices that relied on LiveAnalytics defaulting the time to arrival will need a firmware or gateway change.

Step 3: rewrite queries and validate

LiveAnalytics uses a SQL dialect with its own time functions such as ago(), bin() and interpolate_linear, while InfluxDB 3 supports SQL and InfluxQL on DataFusion. Expect to rewrite time-bucketing and interpolation queries rather than copy them. The right validation is not eyeballing a dashboard but comparing row counts per day and a handful of aggregates (sum, min, max, percentile) per device for sample windows across both systems. Discrepancies in the first and last day usually mean a timezone or boundary-inclusion difference.

Step 4: cut over deliberately

Move dashboards in order of risk: internal engineering first, operations second, customer-facing last. Keep dual-writing for at least one full retention-boundary cycle so you can roll back. Then set LiveAnalytics retention to the minimum, let it age out, and delete the tables. Remember that decommissioning is irreversible in a practical sense: because new customers cannot sign up, a deleted-then-regretted LiveAnalytics account cannot be recreated, which is a reason to export a final archive to S3 before deleting.

Decision Matrix: Comparing the Options Side by Side

The table summarises the verified characteristics of each option. Empty cells would indicate “not documented”, and where I could not verify a property I say so rather than guess.

Criterion	LiveAnalytics	InfluxDB 2 on Timestream	InfluxDB 3 on Timestream	Amazon Keyspaces	S3 + Iceberg + Athena
Open to new AWS customers	No, since June 20, 2025	Yes	Yes	Yes	Yes
Scaling model	Serverless	Instance size, Multi-AZ	Nodes, up to 15 in Enterprise	Serverless request units	Serverless, per scan
Storage substrate	Memory plus magnetic stores	Provisioned volume up to 16 TiB	Parquet on S3	Managed LSM storage	Parquet on S3
Query interface	SQL dialect	Flux, InfluxQL	SQL, InfluxQL	CQL only	SQL (Trino or Presto based)
Cardinality guidance	128 dimensions per table	Under 10 million series per instance	Designed for very high cardinality (vendor claim)	Not applicable, key-based	Not applicable
Aggregations in engine	Yes	Yes	Yes	Minimal	Yes
Billing basis	Writes, GB-hours, TCU-hours	Instance-hours, storage	Node-hours, S3 storage	Request units, storage	Scan bytes, S3 storage
Best latency profile	Recent data fast	Single-digit ms operational	Real-time analytics	Predictable key lookups	Seconds to minutes
Multi-Region story	Not documented here	Not documented here	Not documented here	Multi-Region replication	S3 cross-region replication

Read the table as a map of failure modes. LiveAnalytics fails you on availability, InfluxDB 2 on scale-up ceilings, InfluxDB 3 on cost predictability at idle, Keyspaces on analytics and the lake on latency. No option fails on everything, and the right design often composes two of them, as in the reference architecture above.

Scoring by workload type

For IoT fleet telemetry with ad hoc engineering queries, I rank InfluxDB 3, then the lake alone, then Keyspaces with a rollup layer. For industrial plants with operator HMIs that need very fast reads, InfluxDB 2 on a Multi-AZ instance or an InfluxDB 3 cluster with reader nodes. For consumer devices whose app shows per-device history, Keyspaces. For FinOps and compliance archives, the lake. These are opinionated rankings based on the properties above, not benchmark results.

What about Timescale, ClickHouse and Grafana?

AWS does not sell a first-party managed Timescale or ClickHouse; they are available through their vendors’ own cloud services or as self-managed software on EC2, EKS or RDS-compatible services, and the licensing and extension availability differ by service. I have not verified current extension support on Aurora or RDS, so check before assuming TimescaleDB features are available there. If you want a real columnar OLAP engine for high-cardinality telemetry, read our ClickHouse versus Druid versus Pinot decision record and the Postgres 18, TimescaleDB and ClickHouse comparison. Grafana works against InfluxDB through its InfluxDB data source, and against Athena through the Athena plugin; confirm plugin versions in your Grafana release.

Trade-offs, Gotchas, and What Goes Wrong

Every option above has a failure mode that tends to appear in month three, not week one. These are the ones worth testing deliberately.

Whole-batch rejection. Both the IoT Core InfluxDB action and the underlying InfluxDB write API treat a batch as atomic. One point whose field changes from integer to float fails all 200 points in that batch. Defend with schema validation at the edge or in rule SQL, and with the error action capturing failures. Alert on the error table’s row rate, not just on the main table.

Timestamp contract drift. The IoT action rejects ts or time aliases and does not stamp arrival time. Firmware that sends seconds where the action expects milliseconds writes data into January 1970 or the year 50,000 without erroring, and your dashboards show empty “last hour” windows. Add a sanity range check at the gateway, and a canary query that alerts when the newest timestamp falls outside now plus or minus a tolerance.

Cardinality creep. Someone adds firmware_build or request_id as a tag. On InfluxDB 2 the series count crosses the 10 million guidance and memory climbs until the instance restarts. On InfluxDB 3 you get slower queries and bigger indexes instead of an outage, but the cost is real. Review tag additions like schema migrations.

Compactor lag. In an InfluxDB 3 Enterprise cluster, one dedicated compactor handles background Parquet compaction. If ingest outruns it, queries touch many small files and slow down. Track compaction lag as a first-class SLO; our SLO and burn-rate alerting guide for IoT platforms shows how to express it.

Idle cost. Node-hour billing means a quiet cluster still costs money. Right-size reader nodes to the dashboards you actually have, and use the add-and-remove-nodes capability rather than permanently provisioning for the worst hour.

Hot partitions in Keyspaces. A time bucket that is too coarse, or a single device that is far chattier than its peers, concentrates writes in one partition. The symptom is throttling on a table well below its quota. Fix it with a finer bucket or a synthetic shard suffix in the partition key.

Late data in LiveAnalytics. As covered earlier, records older than the memory window are rejected without magnetic store writes. Test your reconnect-and-replay path with an eight-hour outage, not a five-minute one.

Regional and DR gaps. The documentation I reviewed does not describe cross-Region replication for the InfluxDB offerings. If your recovery objective spans Regions, plan an explicit export-to-S3 with cross-Region replication, and test restoration. AWS added backup and restore actions to its InfluxDB managed policies in August 2026, which suggests backups are API-driven, but I did not verify the retention or restore semantics.

Vendor-claim hygiene. Figures such as millions of points per second across hundreds of millions of series come from InfluxData’s own announcement and customer stories, not from an independent benchmark. Run your own load test with your tag layout before committing.

Practical Recommendations

The design principle that ties this together: pick the engine for the questions you will ask, and keep the raw data in an open format so the engine can change. The 2025 availability change was a reminder that managed services can be closed to newcomers, and Parquet in your own S3 bucket outlives any product line.

For a new workload that needs live dashboards, start with Timestream for InfluxDB 3. Use Core for a proof of concept and development, and plan for Enterprise when you need high availability or multi-node scale, remembering that an upgrade path from Core exists. Keep an S3 copy through Firehose from day one. If your team is small and the series count is modest, InfluxDB 2 on Multi-AZ is simpler and cheaper to reason about.

For existing LiveAnalytics estates, do not panic and do not stall. Inventory tables by write rate, query cost and downstream consumers, then migrate the cheapest, most isolated table first to learn the data-model mapping. Budget real time for query rewrites; they are the long pole.

For a Keyspaces design, commit to the access pattern in writing before you create the table. If a stakeholder later asks for cross-device aggregates, add the lake or a rollup path rather than bending the table.

A short pre-production checklist:

Confirm device payloads carry a numeric timestamp in the unit set on the rule action.
Add an error action and an alert on its write rate.
Cap tag cardinality in review, and keep unique identifiers in fields.
Model cost with node-hours or request units at peak and at idle.
Load test with your real tag layout and an eight-hour replay.
Land raw data in S3 Parquet regardless of the hot-path choice.
Document the exit path and test one restore from backup.
Re-verify pricing, quotas and regions in the console, as these change.

Frequently Asked Questions

Is Amazon Timestream being discontinued?

Not as a whole. AWS closed Timestream for LiveAnalytics to new customers effective June 20, 2025, but says existing workloads are unaffected and that it continues to invest in security, availability and performance. Timestream for InfluxDB remains open, supports InfluxDB 2 and 3, and received feature updates through 2026, including multi-node clusters. New projects should target the InfluxDB variant, and existing LiveAnalytics users should plan a migration on their own schedule.

Should a new project use Timestream for LiveAnalytics?

You generally cannot. New customer access is closed, and AWS recommends that new customers evaluate Timestream for InfluxDB because of its similar functionality. If your organisation already has an active payer account using the service, you can keep adding users and linked accounts under it, but building anything new on a closed product adds migration debt. Default to InfluxDB 3 unless you have a specific reason not to.

What is the difference between InfluxDB 2 and InfluxDB 3 on Timestream?

InfluxDB 2 runs on provisioned instances with a single writer, queried via Flux or InfluxQL, with AWS guidance to keep cardinality under 10 million series per instance. InfluxDB 3 rebuilds the engine on Arrow, DataFusion and Parquet in S3, supports SQL and InfluxQL, and in its Enterprise edition scales to multi-node clusters of up to 15 nodes. Choose 3 for analytics and large cardinality, 2 for small low-latency estates.

Can AWS IoT Core write directly to Timestream for InfluxDB?

Yes. Since August 25, 2026 IoT Core has an InfluxDB rule action that converts JSON device messages to line protocol and writes to managed or self-hosted InfluxDB, versions 2 and 3. It requires a timestamp key in the payload, HTTPS endpoints, and credentials in Secrets Manager. It supports server-side batching of up to 500 points, and a single invalid point fails the whole batch.

Is Amazon Keyspaces a good time-series database?

It is a good store for time-ordered data read by key, and a poor analytics engine. Model partitions as device plus a time bucket with a timestamp clustering key, expect to stay within 40,000 read and write units per second per table by default, and use TTL for retention. For cross-device aggregations, pair it with S3 and Athena or move to InfluxDB 3, since Keyspaces offers minimal in-engine aggregation.

How do I migrate from LiveAnalytics to InfluxDB?

Export tables to Amazon S3, map dimensions to tags and measure values to fields, load into Timestream for InfluxDB 3, and dual-write new data through IoT Core rules during the transition. Rewrite queries that use LiveAnalytics-specific time functions, validate with per-day row counts and aggregates, then cut dashboards over gradually. AWS documents S3 as the intermediate layer for all migration targets, including InfluxDB 2 and Aurora PostgreSQL.