Time Series Databases Overview

Time-series data is append-mostly, timestamped, queried over ranges, and less valuable as it ages. Every time-series database is a set of answers to the same six questions.

Why general-purpose databases struggle

A row store writes each point as a row with full overhead and indexes it as if it were random. A billion points a day means a billion rows, an index that no longer fits in memory, and a retention policy implemented as a DELETE that generates bloat.

Time-series engines exploit the structure instead: partition by time so retention is a partition drop; store values columnar and delta-encoded so compression is high; and index by series rather than by row.

The three covered here

TimescaleDB — a PostgreSQL extension. Full SQL, joins against relational data, and the PostgreSQL operational model. The right choice when time-series data must be queried alongside business data, or when the team already runs PostgreSQL.

VictoriaMetrics — a Prometheus-compatible metrics database focused on ingestion efficiency and low storage cost. The right choice for infrastructure and application metrics at scale, where PromQL is the query language you want.

InfluxDB — purpose-built for time series. Note that its storage engine and query language changed substantially between major versions, so version matters more here than with most engines when reading documentation or evaluating tooling.

Choosing

• Metrics from Prometheus-style exporters, at high volume → VictoriaMetrics.
• Time-series data joined with relational data, SQL required → TimescaleDB.
• Wide event data with ad-hoc analytical queries → consider ClickHouse instead; it handles this well, at the cost of building retention and downsampling yourself.
• IoT or sensor telemetry with a self-contained stack → InfluxDB, verifying the version's query language and clustering story matches your requirements.