Choosing a time-series database for metrics

WHY IT EXISTS Application metrics are a special data shape: huge volumes of append-only, timestamp-ordered points, rarely updated, queried almost always by time range and aggregated into windows. General relational engines are built for varied transactional access, not this firehose. Time-series databases specialize for it.

A GOOD ANSWER COVERS When to choose a TSDB. Pick one when you have sustained high-cardinality, high-frequency writes of timestamped measurements and your queries are time-bounded aggregations: averages per minute, rates, percentiles over a window, last-value per series. The key advantages are ingest paths optimized for ordered, append-mostly writes; storage engines with time-aware delta and columnar compression that cut disk use enormously versus row storage; automatic retention policies that expire old data; downsampling and continuous or rollup aggregates that precompute coarse summaries; and built-in time functions like windowing, gap-filling, and rate calculation that are awkward in plain SQL.

THE TRADE-OFFS A TSDB is narrower: it optimizes for time and sacrifices the general-purpose joins, rich constraints, and arbitrary transactional updates a relational database offers. For modest metric volumes, Postgres, especially with the TimescaleDB extension, is often enough and keeps your data in one familiar system.

LIKELY FOLLOW-UPS What is high cardinality and why does it stress a TSDB, how do retention and downsampling work, and when does TimescaleDB on Postgres beat a standalone TSDB.

ONE CONCRETE EXAMPLE Storing CPU and request-latency samples every ten seconds across thousands of hosts produces billions of points monthly. A TSDB compresses these heavily, expires data older than 90 days automatically, and answers a per-minute p99 over the last hour with a built-in window function, whereas a naive Postgres table would bloat and need hand-rolled rollups.