Time-Series Database

A time-series database (TSDB) stores measurements that arrive in time order. Each record is a value plus a timestamp plus some labels that say where it came from. For example: cpu_usage = 73.2 at 14:05:01 on host web-03 in region us-east. Over a day a single server can produce millions of these points, and a fleet of thousands of servers produces billions.

The defining trait is that writes are almost always appends of new, recent data, and reads are almost always queries over a time range like the last 5 minutes or the last 30 days. You rarely update a point after it was written, and you rarely look up a single point by an arbitrary id. A TSDB is tuned hard around that pattern, which is why a general purpose relational table with a timestamp column eventually struggles at scale.

Common TSDBs include InfluxDB, TimescaleDB (a Postgres extension), Prometheus (for monitoring), and Amazon Timestream. ClickHouse and Apache Druid are column stores that are also frequently used for time-series workloads.

Because data arrives in time order and is rarely changed, a TSDB can store it in large append-only blocks sorted by time. New points go into an in-memory buffer, are written to a write-ahead log for durability, and are periodically flushed to immutable on-disk blocks. This keeps writes cheap and avoids the random-write overhead that hurts B-tree indexes when you constantly insert recent rows.

On disk the data is usually stored column by column rather than row by row, so all the cpu_usage values sit next to each other. Columnar layout compresses extremely well for time-series because consecutive values are similar. Techniques like delta-of-delta encoding for timestamps and Gorilla XOR compression for floats, used by Facebook's Beringei and InfluxDB, can shrink data by 10x or more.

Old blocks are compacted and merged in the background. Most TSDBs add retention policies that automatically delete data past a cutoff, and continuous downsampling that rolls raw points into 1-minute or 1-hour averages so long-range queries stay fast. Labels are indexed separately (an inverted index) so you can quickly find all the series matching host=web-03 without scanning everything.

Reach for a TSDB when your data is naturally a stream of timestamped measurements and your queries are time-bounded: infrastructure monitoring, application metrics, IoT and sensor telemetry, financial ticks, event analytics, and real-time dashboards. The payoff is high ingest throughput, strong compression, and built-in time functions like rate, moving average, and bucketed aggregation.

The trade-offs are real. A TSDB is not a general purpose store. Updating or deleting individual points is slow or unsupported. High-cardinality labels (for example, a unique user id attached to every metric) can blow up the index and memory use, which is the single most common way teams break Prometheus and InfluxDB. Joins across unrelated datasets are weak compared to a relational database.

A useful middle path is TimescaleDB, which runs inside PostgreSQL. You keep full SQL, joins, and your existing tooling, and the extension transparently partitions tables into time-based chunks for TSDB-style performance. If you already run Postgres, that often beats adopting a separate system.

Picture a monitoring setup for 2,000 servers. Each server reports about 200 metrics every 15 seconds. That is 2000 x 200 / 15, roughly 26,000 points per second, around 2.3 billion points per day. A row-per-point relational table with an index would spend most of its time on index maintenance and would balloon in size.

Prometheus or InfluxDB ingests this comfortably on a single node. It compresses the 2.3 billion daily points down to a few gigabytes, answers a dashboard query like average CPU per region over the last hour in milliseconds, and automatically drops raw data after 15 days while keeping 1-hour rollups for a year. A query language function such as rate(http_requests_total[5m]) computes per-second request rates from a counter without you writing windowing logic by hand.

This is the workload Grafana dashboards are built on: a TSDB underneath, a label-based query on top, and time on the x axis.