What Time-Series DBs Solve

A time-series database stores time-stamped numeric data: (timestamp, value, labels).

Examples:

• CPU usage on host-x every second.
• Stock prices per second.
• IoT temperature sensors every minute.
• Application metrics: request rate, latency, error count.

Workload pattern:

• Write-heavy: 100k-1M points/sec from many sources.
• Append-only: timestamps monotonic; old data rarely modified.
• Time-bounded reads: "last 1h", "yesterday", "last 30 days".
• Aggregation-heavy: avg/percentile/rate over time windows.
• Many series: 1M+ unique series (host × metric × tag combos).

Why not Postgres?

• High write rate overwhelms B-tree indexes.
• Storage cost: each row carries timestamp + labels.
• No time-window-friendly primitives.

Real systems:

• Prometheus: pull-based, embedded TSDB, monitoring focus.
• InfluxDB: push-based, multi-tenant, SQL-like.
• TimescaleDB: Postgres extension; hypertables for partitioning.
• VictoriaMetrics: Prometheus-compatible, very fast.
• OpenTSDB / KairosDB: HBase-backed.
• Datadog, AWS Timestream, Azure Monitor: cloud TSDBs.

Architecture overview:

Ingest (push or pull) → Buffer → Indexer → Storage (compressed blocks)
                                          ↓
                            Query Layer ←─┴──→ Compaction

Storage tricks:

• Time partitioning: each shard = a time window (e.g., 2h block).
• Per-series chunks: each (metric, tags) → its own column-store-like file.
• Heavy compression: timestamps + values often compress 50-100x with delta + zigzag + Gorilla.