Time-series data: measurements indexed by time. Sensor readings, metrics, financial ticks, log events. Each point has a timestamp; you usually query ranges of time.
General-purpose databases handle this poorly at scale. Time-series databases are optimized for the specific access patterns.
This page covers when they fit and the major options.
Mostly inserts, append-only. Updates rare; deletes mostly via retention.
metric_name | timestamp | value | tags
cpu_usage | t1 | 0.45 | host=A region=us
cpu_usage | t2 | 0.47 | host=A region=us
cpu_usage | t3 | 0.52 | host=A region=us
Each insert is small; the volume is enormous.
Data has retention: keep raw for 30 days, downsampled for 1 year, monthly aggregates for 5 years. Older data automatically deleted.
A typical PostgreSQL setup with B-tree indexes on timestamp + tags: indexes get huge as data grows. Inserts slow.
Computing "average over 1 hour" requires scanning many rows. Without specialized storage, slow.
Time-series data compresses extremely well (similar values close in time). General DBs don't optimize for this.
Deleting old data is expensive in MVCC databases. Time-series DBs handle this efficiently via partitioning.
Purpose-built time-series database. Tag-based; SQL-like query language (Flux); good performance.
InfluxDB 1.x vs. 2.x: significant changes; the v2 API is different. Pick deliberately.
PostgreSQL extension. Time-series features (chunked storage, automatic partitioning) on top of PostgreSQL.
For organizations that want PostgreSQL ecosystem + time-series performance.
Metrics-focused. Pull-based (scrapes targets). Built-in query language (PromQL). Limited durability — typically used with long-term storage backend (Thanos, Cortex, Mimir).
Standard for Kubernetes/cloud-native monitoring.
Real-time analytics on time-series. Heavyweight; for large-scale analytics.
Columnar OLAP database. Very fast aggregations; not strictly time-series but used for it.
Managed time-series on AWS. Serverless; pay-per-use.
For most use cases:
High-resolution data is expensive to store long-term. Periodically aggregate:
Raw 1-second data → 1-minute averages (kept 90 days) → 1-hour averages (kept 1 year)
Most time-series DBs have automated downsampling.
TimescaleDB feature: precomputed aggregates that update incrementally. Queries hit the precomputed view instead of raw data.
Time-series points have tags ("host=A", "region=us"). Tags index the data; queries filter and group by tags.
Cardinality matters: too many distinct tag combinations explode storage.
Built-in: "keep raw 30 days; aggregated 1 year; monthly summaries forever."
Without retention: data grows until storage fills.
Time-series compresses 10-100x. The DB handles this; you don't manage manually.
Order created at time T isn't really "time-series" — it's an order. Use a relational DB.
Time-series DBs assume append-mostly. Update-heavy workloads don't fit.
Some time-series DBs are limited in query expressiveness. For complex analysis, OLAP or warehouse.
A few thousand points per day fit in any database. Don't introduce time-series infrastructure for small needs.
The biggest scaling concern. Each unique combination of tags is a "series."
Bad:
tags: user_id=user-123 ← creates a new series for every user
Good:
tags: country=US, plan=premium ← bounded set
High cardinality (millions of series) crushes most time-series DBs. Plan tag schemas accordingly.
For monitoring needs: Prometheus + Grafana for current; long-term storage (Thanos/Mimir) if retention matters.
For application time-series: TimescaleDB. Familiar SQL; strong performance.
For very high-cardinality or specialized needs: evaluate InfluxDB, ClickHouse.