Time-Series Databases

A time-series database (TSDB) is built around one assumption: most of your data is timestamped, append-mostly, and rarely updated. That assumption changes everything — storage format, compression, query language, retention. The result is a database that holds billions of points per server cheaply, and answers "how did this metric look over the last 24 hours" in milliseconds.

You already use TSDBs without thinking about it. Prometheus is a TSDB. CloudWatch is one. DataDog is one. But there's a category of general-purpose TSDBs you reach for when Prometheus' scope (operational metrics, short retention) isn't enough — IoT data, business analytics, financial ticks, application traces in raw form.

Why a TSDB and Not Postgres

You can store timestamps in Postgres. At small scale it's fine. At any real scale it falls over:

The breaking point is usually when you have millions of series × billions of points and queries scan large time ranges. At that scale, a TSDB is 10-100× cheaper and faster than Postgres on the same hardware.

The Players

How to pick:

• Need SQL and Postgres ecosystem → TimescaleDB
• Operational metrics already on Prometheus → VictoriaMetrics or Mimir for long-term
• IoT / massive write rate → InfluxDB v3 or TDengine
• Finance / tick data → QuestDB or kdb+ (commercial)
• Trillions of rows analytics → ClickHouse (technically OLAP, but eats time-series)
• Don't want to run anything (AWS) → Timestream

For most teams starting out: TimescaleDB if you already use Postgres; InfluxDB otherwise.

What's Different About Time-Series

The shape of the data changes everything:

Cardinality: The Silent Killer

A series is one unique combination of metric + tag values. Each is a distinct stream of points. If you have:

http_requests{service="checkout", region="us-east-1", status="200", user_id="u_123"}

Then user_id is the killer — every user creates a new series. High-cardinality labels destroy TSDBs. Rules of thumb:

Cardinality budget: most TSDBs handle 1-10M active series per node well; above that, things start hurting. Prometheus, InfluxDB v1/v2 are most sensitive; v3 / VictoriaMetrics / Mimir handle more.

If you need per-user metrics, use logs/traces (low aggregation cost) — not high-cardinality time-series.

Retention and Downsampling

Time-series data ages predictably. Treat older data differently:

0-7 days:    full resolution (1s)
7-30 days:   1min downsampled  (60x cheaper)
30-90 days:  5min downsampled
90-365 days: 1h downsampled
> 1 year:    archived or dropped

This is continuous queries in InfluxDB, continuous aggregates in TimescaleDB, recording rules in Prometheus. The downsampled data lives next to the raw data; queries hit whichever resolution matches the time range.

Without downsampling, year-old 1-second metrics cost the same to store as today's — that bill grows linearly forever.

Learning Path

Time-Series vs Adjacent Storage

The lines blur. ClickHouse routinely handles "TSDB" workloads better than dedicated TSDBs above a certain scale. TimescaleDB is Postgres so does both transactional and time-series in one place. Apache Druid straddles OLAP and TSDB. Pick the database that fits your query patterns, not the marketing category.