Server metrics every 10 seconds, sensor readings from thousands of devices, stock ticks, application events: time-series data is append-mostly, timestamped and arrives continuously, and it’s usually queried by time range. General-purpose databases can store it, but time-series databases (TSDBs) are built to ingest it fast, compress it well, and answer “average CPU per host over the last 7 days in 5-minute buckets” quickly.
What makes time-series data different
- Write-heavy: many small inserts, rarely updated.
- Time-ordered queries: ranges, aggregates over windows, latest values.
- High volume: a few hundred metrics × many hosts × every few seconds adds up fast.
- Ages out: detailed data matters for days, summaries for months or years.
TSDBs optimise for exactly this, with columnar or chunked storage, heavy compression (often 10–20×), time-partitioned data, automatic retention (deleting old data) and downsampling (keeping hourly averages after a week).
The main options
| Database | Model | Query language | Best for |
|---|---|---|---|
| Prometheus | Pull-based metrics with labels | PromQL | Infrastructure and app monitoring, alerting |
| VictoriaMetrics | Prometheus-compatible, efficient | PromQL / MetricsQL | Long-term, large-scale metrics storage |
| InfluxDB | Measurements, tags, fields | SQL / InfluxQL (v3), Flux (v2) | IoT, metrics, events |
| TimescaleDB | PostgreSQL extension (hypertables) | Full SQL | Time-series alongside relational data |
| ClickHouse | Columnar OLAP | SQL | Huge event and analytics datasets, logs |
| QuestDB | Columnar, time-series | SQL | High ingest, financial data |
Prometheus
The standard for monitoring. Prometheus scrapes metrics from exporters (node_exporter, database exporters) and applications, stores them locally, and evaluates alert rules. Grafana visualises it. It isn’t designed for long-term storage or event data. Pair it with VictoriaMetrics, Thanos or Mimir for long retention. See Prometheus and Grafana.
InfluxDB
Purpose-built for time-series, with an easy HTTP write API (the line protocol). It’s popular for IoT and custom metrics (Telegraf collects from hundreds of sources). Version differences matter (1.x, 2.x and 3.x have different query languages and features), so check which one your tools support. See install InfluxDB.
TimescaleDB
Time-series inside PostgreSQL: tables become “hypertables” automatically partitioned by time, with compression, continuous aggregates and retention policies. Ideal when you want SQL, joins with your relational data, and one database to operate. See install TimescaleDB.
ClickHouse
A columnar analytics database that’s extremely fast at aggregating billions of rows. It’s excellent for event analytics, logs and web analytics (Plausible and others use it), and also for time-series at scale. See install ClickHouse.
How to choose
| Situation | Choose |
|---|---|
| Monitor servers and apps, with alerting | Prometheus (+ Grafana), with VictoriaMetrics for long-term |
| IoT devices pushing sensor data | InfluxDB or TimescaleDB |
| Time-series plus relational data, SQL skills | TimescaleDB |
| Huge event or log analytics | ClickHouse |
| Simple app metrics, small scale | Your existing PostgreSQL (maybe with TimescaleDB) |
Design tips
- Labels and tags with care: every unique combination of tag values is a separate series. Putting user IDs, request IDs or full URLs in tags explodes the cardinality, and with it memory and performance. Keep high-cardinality values in fields or logs.
- Pick the right resolution: collect at the frequency you actually need (10–60 s for most server metrics).
- Set retention from day one: e.g. raw data for 15–30 days, downsampled hourly data for a year.
- Separate metrics, logs and traces: use the right tool for each (TSDB for metrics, Loki or OpenSearch for logs, Tempo or Jaeger for traces).
Running a TSDB on a VPS
- Disk: fast SSD storage helps ingestion and queries. Compression keeps the totals modest. See fio disk benchmark.
- RAM: Prometheus and InfluxDB memory grows with active series (cardinality). Monitor the monitoring.
- Backups: snapshots or exports to off-server storage. Metrics are often less critical than business data, but dashboards and alert history still matter. See backup strategy.
- Security: bind to private networks. Prometheus has no authentication by default, so put it behind a reverse proxy with auth or a VPN.
Quick reference
| Tool | One-line summary |
|---|---|
| Prometheus | Pull-based monitoring with PromQL and alerting |
| VictoriaMetrics | Efficient long-term Prometheus storage |
| InfluxDB | Purpose-built TSDB, push-based, IoT-friendly |
| TimescaleDB | Time-series on PostgreSQL with full SQL |
| ClickHouse | Columnar analytics at massive scale |
Related: DuckDB and SQL vs NoSQL.