Amazon Timestream for Time-Series Data

Amazon Timestream is a serverless, fully managed time-series database service designed to handle the unique characteristics of time-series data: high write volume, append-only nature, time-based queries, and data that becomes less valuable as it ages. Traditional relational databases struggle with time-series data because they are optimized for ACID transactions and complex joins, not for the high-frequency inserts and range scans typical in IoT, DevOps, and industrial telemetry. Timestream addresses this by using a two-tier storage model: an in-memory store for recent, frequently accessed data, and a magnetic store for older, less-accessed data. The service automatically moves data between tiers based on a configurable retention policy. It also provides built-in time-series functions like AVG(), SUM(), MIN(), MAX(), and SAMPLE_BY() for downsampling and aggregation, eliminating the need for custom logic.

Timestream stores data in a database that contains tables. Each table has a schema that includes measures (numeric values) and dimensions (metadata). When you write a record, you specify a timestamp, one or more measure values, and dimension key-value pairs. Timestream automatically partitions data by time and by dimensions. For example, if you have a sensor that reports temperature and humidity every second, each record might look like this:

{
  "Time": "2025-04-09T12:00:00Z",
  "MeasureValueType": "DOUBLE",
  "MeasureName": "temperature",
  "MeasureValue": "23.5",
  "Dimensions": [
    {"Name": "sensor_id", "Value": "sensor-01"},
    {"Name": "location", "Value": "warehouse-a"}
  ]
}

Timestream indexes data by time and dimensions. When you query, you specify a time range and optionally filter by dimensions. The query engine uses the time index to skip partitions outside the range. For recent data (in memory store), queries are low-latency. For older data (magnetic store), the engine uses columnar storage and compression to reduce I/O. Timestream also supports automatic time-to-live (TTL) to delete data older than a specified retention period (up to 10 years for magnetic store).

To create a database and table using the AWS CLI:

aws timestream-write create-database --database-name MyTimeSeriesDB

aws timestream-write create-table --database-name MyTimeSeriesDB --table-name SensorData \
  --retention-properties MemoryStoreRetentionPeriodInHours=24,MagneticStoreRetentionPeriodInDays=365

To write a record:

aws timestream-write write-records --database-name MyTimeSeriesDB --table-name SensorData \
  --records '[{"Time":"2025-04-09T12:00:00Z","MeasureValueType":"DOUBLE","MeasureName":"temperature","MeasureValue":"23.5","Dimensions":[{"Name":"sensor_id","Value":"sensor-01"},{"Name":"location","Value":"warehouse-a"}]}]'

To query data (using the query endpoint):

aws timestream-query query --query-string "SELECT sensor_id, AVG(measure_value::double) AS avg_temp FROM \"MyTimeSeriesDB\".\"SensorData\" WHERE time BETWEEN '2025-04-09T00:00:00Z' AND '2025-04-09T23:59:59Z' GROUP BY sensor_id"

Scenario 1: IoT Sensor Monitoring at a Smart Factory

A manufacturing plant has thousands of sensors collecting temperature, vibration, and pressure data every second. They need to monitor real-time conditions and analyze historical trends for predictive maintenance. They choose Timestream because it can ingest high-velocity data without provisioning capacity. They configure an AWS IoT Core rule to write sensor data directly to a Timestream table named SensorData. The retention policy is set to 24 hours for memory store (for real-time dashboards) and 365 days for magnetic store (for monthly reports). They use QuickSight to build dashboards that show current readings and hourly averages. A common issue they encounter is that queries without time filters are slow and expensive. They learn to always include a time range. They also set up a scheduled query to compute daily aggregates and store them in a separate table to reduce query costs.

Scenario 2: DevOps Monitoring for a Cloud Application

A SaaS company monitors CPU, memory, and disk usage for thousands of EC2 instances. They send metrics to Timestream via CloudWatch Logs subscription filters and Lambda. They use Timestream's built-in functions to detect anomalies (e.g., CPU > 90% for 5 minutes). They also use scheduled queries to generate weekly reports. A mistake they made was not setting an appropriate memory store retention period; they kept data in memory for 7 days, which increased costs. They optimized by reducing to 24 hours. They also learned that Timestream does not support JOIN operations, so they denormalize their dimensions (e.g., include instance type and region as dimensions) to avoid needing joins.

Scenario 3: Financial Market Data Analysis

A fintech startup ingests stock trade data at 1,000 records per second. They use Timestream to store trade prices and volumes. They query for moving averages and volatility. They use the SAMPLE_BY function to downsample from per-second to per-minute data. A challenge they faced was that Timestream's query timeout is 60 seconds, so complex queries over large time ranges (e.g., 1 year) would time out. They solved this by using scheduled queries to precompute daily summaries. They also had to request a throughput increase from 10,000 to 50,000 records per second.