Time-series data and Amazon Timestream

Timestream for LiveAnalytics is closed to new customers

The Timestream engine described in most existing material — Amazon Timestream for LiveAnalytics, with its memory and magnetic storage tiers and its own SQL dialect — has been closed to new customers since 20 June 2025. A new AWS account cannot create one. Amazon Timestream for InfluxDB is the offering AWS now sells, and AWS directs customers wanting LiveAnalytics-like capabilities to it. Existing LiveAnalytics deployments continue to run; new work should not start there.

Time-series data

Time-series data is a sequence of values logged against time, where the timestamp is part of the identity of the record rather than metadata about it. Temperature readings from weather stations, hourly, for years, are the canonical example.

The category is distinct because the access patterns are so lopsided. Writes are overwhelmingly appends at the current time. Reads are almost always range queries over a window, frequently aggregated into buckets. Old data is rarely read and is usually downsampled or discarded on a schedule. Records are small, numerous and highly compressible.

A relational database can store this, and does so badly at volume: a row-oriented index optimised for random access is the wrong structure for billions of small appends and whole-range scans, and the storage cost of keeping raw readings indefinitely in an OLTP engine is difficult to justify.

Purpose-built time-series databases exploit the pattern instead — columnar or delta-encoded storage that compresses timestamps and values aggressively, tiered storage that moves recent data to memory and history to cheaper media, retention policies that expire or downsample automatically, and query functions for interpolation, smoothing and gap-filling that a general-purpose SQL engine does not provide.

Where it comes from

Internet of things. Sensor fleets producing readings continuously — agricultural soil and weather sensors, industrial machinery telemetry, building management systems. Volume scales with the number of devices and the sampling rate, and both tend to grow.

Application and infrastructure metrics. Request rates, latencies, error counts, resource utilisation. Continuous monitoring is what allows a system to be scaled correctly and diagnosed after the fact.

Web and network analytics. Traffic volumes, throughput and quality-of-service measurements at a scale where every observation is a data point.

Amazon Timestream for InfluxDB

Timestream for InfluxDB runs the open-source InfluxDB engine as a managed service on AWS, which means the query languages, client libraries and tooling are InfluxDB’s rather than proprietary.

• InfluxDB 3 Enterprise runs as a multi-node cluster, so ingestion and query capacity can be scaled separately, and AWS positions it for single-digit millisecond query response.
• InfluxDB 2 remains available for workloads that need Flux compatibility.

The practical appeal is the same as any managed open-source database: the engine and its ecosystem are not AWS-specific, so the workload is portable, while AWS handles the provisioning, patching, backup and availability.

Alternatives worth considering

Timestream is not the only answer, and for many workloads it is not the best one.

• Amazon CloudWatch already collects application and infrastructure metrics, with alarms, dashboards and integrations. If the requirement is monitoring rather than analysis, a time-series database is an extra system solving a problem CloudWatch already solves.
• Amazon Managed Service for Prometheus suits metrics from containerised and Kubernetes workloads, where Prometheus is already the ecosystem in use.
• S3 plus Athena suits high-volume telemetry that is queried occasionally rather than continuously, at a fraction of the storage cost.
• Self-managed InfluxDB, TimescaleDB or ClickHouse remain viable where the operational work is acceptable and the engine choice matters.

The question that decides between them is how the data will be read. Continuous dashboards and alerting point at CloudWatch or Prometheus; ad hoc analysis over a long history points at a data lake; sustained high-rate ingestion with interactive queries over recent data is what a time-series database is for.