Specialized stores where every row has a timestamp and a few tags, writes arrive monotonically, and reads are almost always "this metric, this tag set, this window, downsampled." Tuned end-to-end for that one shape.
← Back to Database Sidecpu_usage{host=web-1,region=us-east-1}). The unit of identity.user_id as a tag is how you destroy a TSDB.The Kubernetes-era metrics standard. Pull-based scraping, PromQL, alerting built in. Single-node — pair with Thanos / Cortex / Mimir for long-term storage and HA.
The original purpose-built TSDB. v2 brought Flux; v3 (IOx) is a Parquet + DataFusion rewrite. Strong UX for IoT and observability.
A Postgres extension. Hypertables partition by time automatically; you keep all of SQL, joins, and the Postgres ecosystem. The pragmatic pick when you also need relational data.
Horizontally scalable, Prometheus-compatible. The path most large infra teams take when single-node Prometheus stops fitting.
Columnar engines that double as time-series stores. Fast ingest, SQL, and arbitrary analytics — popular in fintech tick data and product analytics.
Managed cloud-native options. ADX (Kusto) is especially strong for log + metric analytics.
CPU, memory, request rate, error rate, latency percentiles. Scraped every 15s, queried by dashboards and alert rules. Prometheus + Grafana is the default stack; for scale, Mimir / Thanos / VictoriaMetrics behind it.
Thousands of devices each sending readings per second. Compression and downsampling earn their keep — raw data is huge, and the questions ("hourly average per device per day") only need summaries.
Quotes, trades, order book updates — millions of events per second per symbol. QuestDB and ClickHouse dominate here because they marry TSDB ingest patterns with arbitrary SQL analytics.
Clickstreams, feature usage, conversions. ClickHouse is increasingly the home of these — PostHog, Plausible, MixPanel-style workloads. TimescaleDB also fits when the data already lives next to relational app data.
Tags are indexed (used in WHERE, GROUP BY); fields are not. Put low-cardinality dimensions (host, region, service) in tags; put the actual measurement (latency_ms, temperature) in fields. Reverse this and queries crawl.
The product of all tag values is the series count. {host} × {endpoint} × {status_code} with 1k hosts, 200 endpoints, 10 statuses = 2M series. Add user_id at 1M users and you've created 2 trillion series — the database will refuse, OOM, or both.
Pre-compute the rollups your dashboards need. Prometheus recording rules, Timescale continuous aggregates, Influx tasks. Dashboards then query small pre-computed series instead of crunching raw points every refresh.
Raw at 15s for 24h, 1m averages for 30d, 1h averages for 2y. Configure per-bucket / per-hypertable. Forgetting this is the most common cause of "why is our metrics bill suddenly $40k."