Time-series database
A database tuned for measurements indexed by time, such as metrics, sensor readings, and values drawn on monitoring charts.
See it
What it is
A time-series database stores measurements whose main coordinate is time: CPU usage every 15 seconds, hourly temperatures, or daily sales totals. It is built for appending points, scanning time windows, grouping into buckets, and expiring old data. Prometheus, InfluxDB, and TimescaleDB are well-known examples with different query and storage models, and Grafana is usually the chart layer reading from them.
Reach for one when most questions sound like 'what happened between these timestamps?', 'what is the rate?', or 'when did this cross a threshold?' Retention and downsampling policies can keep recent data detailed while preserving older history as smaller summaries.
Gotcha: labels can cost more than samples. An unbounded label such as user_id or a raw request URL creates huge numbers of distinct series and can exhaust memory. Keep labels bounded, store event details in logs, and do not assume a metrics store is a good home for arbitrary records.
Ask AI for it
Store these service metrics in TimescaleDB. Create a PostgreSQL hypertable with create_hypertable on recorded_at, index the bounded service and region dimensions, and use time_bucket for hourly rollups. Add a continuous aggregate for request count, error rate, and a TimescaleDB Toolkit percentile_agg rollup read back with approx_percentile for p95 latency, since percentile_cont is not allowed inside a continuous aggregate. Add a 30-day retention policy for raw points, and a one-year policy for hourly summaries. Reject unbounded user_id and raw URL labels, and include queries and tests for late-arriving samples.