Cloud Parts

Time-series databases

A database shaped for measurements stamped with time.

13 technologies on this page ↓
Live model
What you’re watchingReadings are appended in time order. The live chart reads each new row almost at once, while the rollup job wakes periodically and summarizes a batch.

How it works

Time-series databases are built for data that arrives as timestamp, source and value, and is almost always appended rather than updated. They split data into time chunks, compress old chunks heavily, and keep pre-computed rollups so questions like “hourly average for the last 30 days” stay fast. Retention policies drop or downsample old data automatically, which also stops queries that forget a time range from growing without end.

Think of it as

A ship’s logbook with a fresh page every day. Recent pages lie open on the desk; old volumes get summarized and shelved.

Reach for it when

  • IoT and sensor telemetry, infrastructure metrics, market ticks
  • Dashboards over recent windows plus long-term trends
  • High ingest rates where rows are rarely changed

Think twice when

  • Transactional business data with frequent updates
  • Data you don’t mainly query by time

A real example

Pressure readings from thousands of wells land every few seconds in a TimescaleDB hypertable. The live chart reads the last 15 minutes, and a continuous aggregate keeps hourly averages, so a one-year chart reads 8,760 rows instead of millions.

Technologies

Specific products, and what each does differently.

Standalone time-series databases

InfluxDBOpen sourceThe best-known time-series database, fed by line protocol and Telegraf; now in its third generation, a Rust rewrite that keeps data as Parquet files on object storage.QuestDBOpen sourceA columnar time-series database in Java, C++ and Rust that ingests millions of rows a second and answers time-series SQL, with old partitions kept as Parquet.TDengineOpen sourceA clustered time-series database for IoT and industrial data that gives every device its own table, grouped under “supertables” with tags.Apache IoTDBOpen sourceAn Apache time-series database for industrial IoT that stores everything in its own open file format, TsFile, and lets you model devices as a tree of paths or as SQL tables.+1 TimechoDBGreptimeDBOpen sourceA Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.ArcOpen sourceA young single-binary time-series database in Go that writes incoming data as Parquet files and queries them with DuckDB SQL.kdb+CommercialA columnar time-series database that is also an interpreter for q, an array language, used for market data across trading and risk.

What each provider calls it

AWS
Timestream for InfluxDB (Timestream for LiveAnalytics has been closed to new customers since June 2025)
Google Cloud
Bigtable, BigQuery
Azure
Azure Data Explorer
Open source & others
TimescaleDB, InfluxDB, Prometheus, QuestDB, TDengine (IoT, one table per device), Apache IoTDB (industrial IoT; path tree or SQL tables over TsFile), GreptimeDB (metrics, logs and traces on object storage), Arc (DuckDB and Parquet), ArcticDB (Man Group; versioned pandas DataFrames on S3 or LMDB; source-available BSL); proprietary: kdb+ (KX, free Community Edition), used widely in finance

See it in a real stack

Architectures that use time-series databases

IoT telemetry pipelineDevices stream readings into Kinesis; Lambda writes them to TimescaleDB for Grafana, and raw data is archived to S3.Amazon Kinesis Data StreamsAWS LambdaTimescaleDBAmazon S3Grafana

In code · sql

CREATE TABLE readings (time timestamptz NOT NULL, well_id int, psi double precision);
SELECT create_hypertable('readings', by_range('time', INTERVAL '1 day'));

-- hourly rollup, refreshed every hour by a background policy
CREATE MATERIALIZED VIEW readings_hourly WITH (timescaledb.continuous) AS
SELECT time_bucket('1 hour', time) AS hour, well_id, avg(psi) AS avg_psi
FROM readings GROUP BY hour, well_id;
SELECT add_continuous_aggregate_policy('readings_hourly',
  start_offset => INTERVAL '3 hours', end_offset => INTERVAL '1 hour',
  schedule_interval => INTERVAL '1 hour');

Worth exploring

WebsiteDB-EnginesDB-Engines, provided by Redgate SoftwareA directory of hundreds of database systems with their data models, licences and features, which you can compare side by side. Its monthly ranking measures popularity (search results, Google Trends, Stack Overflow questions, job ads, LinkedIn profiles, posts on X), not quality or speed.
All resources →

Benchmarks

Benchmark · Tiger Data (formerly Timescale)Time Series Benchmark Suite (TSBS)A Go toolkit that generates synthetic server-monitoring or IoT time series, bulk-loads it into a database and times a fixed set of time-series queries.7 systems in this catalog · 6 caveats to read first
How to read a benchmark →

Often confused with

Event streamsRelational databasesWide-column storesData warehousesReal-time analytics databasesBitemporal modelingUnbounded queriesMetrics
Where it came from1999–2024

Time-series storage grew out of network monitoring. In late 1997 Tobias Oetiker started RRDtool as a successor to his MRTG traffic grapher, and by 1999 it was in public beta, storing measurements such as network bandwidth, machine-room temperature and server load. Its round-robin database gave each series a fixed number of slots, overwrote the oldest values, and kept extra archives that consolidated older points into averages, minimums and maximums, so storage never grew but detail faded with age. That trade-off survives in today’s retention and downsampling policies.

As fleets of servers grew, so did the metrics. Graphite, built at Orbitz by Chris Davis, was open-sourced in 2008. SoundCloud started Prometheus in 2012 because its monitoring, mostly based on StatsD and Graphite, couldn’t keep up with hundreds of microservices, and InfluxDB followed in 2013. Facebook’s 2015 Gorilla paper showed how far compression could go: by storing timestamps as differences of differences and values XORed with the previous one, it cut storage about tenfold, enough to keep recent metrics in memory.

Others went back to SQL. TimescaleDB, launched in 2017, argued that relational databases handle time series well once the scaling problem is solved, and runs as a PostgreSQL extension. Cloud providers added managed services, such as Amazon Timestream, generally available in September 2020.

Why it’s built this way

Fixed-size storage that forgets detail
RRDtool’s circular buffer kept the storage footprint constant over time. Recent data stayed at full resolution and older data survived only as consolidated averages, minimums and maximums.
Partition by time
New points almost always land in the latest interval, and queries ask for time ranges. Splitting data into time chunks keeps the active chunk small and fast, and dropping old data means deleting whole chunks.
Compress for how measurements change
Timestamps arrive at regular intervals and values change little between readings, so encoding only the change saves a lot: Gorilla stored about 96% of timestamps in a single bit and shrank each 16-byte point to 1.37 bytes on average. Gorilla’s authors also noted that users care about aggregates and recent data more than individual old points.
Label each series with dimensions
Prometheus made a multi-dimensional data model a design goal: each series is a metric name plus key-value labels, so one query can slice by host, region or service.

Timeline

  1. 1999

    Tobias Oetiker’s RRDtool, with its fixed-size round-robin database, is in public beta

  2. 2008

    Graphite, built at Orbitz, is open-sourced

  3. 2012

    SoundCloud starts Prometheus

  4. 2015

    Facebook’s Gorilla paper shows tenfold compression for in-memory metrics

  5. 2017

    TimescaleDB brings time-series storage to PostgreSQL

  6. 2020

    Amazon Timestream becomes generally available

  7. 2024

    Prometheus 3.0, its first major release in seven years

Sources18

Improve this page on GitHub