Don't Panic: Time-Series Databases

A time-series database is where measurements go when they keep arriving with clocks attached. A temperature sensor, latency probe, and request counter all produce a procession of small facts. An ordinary database can store them too, in the same way a cupboard can store a bicycle. The question is whether that arrangement survives when the bicycle arrives every second.

The useful trick is to separate identity from measurement. Tags or labels say which stream a value belongs to: perhaps a service, region, and instance. A field or sample says what changed. Product vocabulary varies because databases enjoy names as much as cats enjoy keyboards, but the decision does not. Choose identity from the questions you need to ask.

This is where cardinality arrives with a clipboard. Each distinct combination of identifying dimensions creates a series. A region is bounded. A request ID is fresh for nearly every request. Put both in the identity and the storage system gets an ever-growing collection of streams, which is less a model and more an archaeological dig with invoices.

Most TSDB questions have a dependable shape: choose a time range, filter series, group observations into windows, then aggregate. A five-minute average can reveal a trend. It cannot bring back the raw sample that showed an unusual spike. That is why retention and downsampling are decisions about future questions, not housekeeping after the disk makes a disapproving noise.

The product names are signposts, not interchangeable containers. InfluxDB uses tables, tags, fields, and time. TimescaleDB brings time partitioning to PostgreSQL tables. Prometheus uses metric names, labels, samples, and PromQL for monitoring. They share changing measurements. They do not share every operational tradeoff, query language, or recovery path.

Start with the Intro for the full architecture. Use Slides for the relationships among identity, values, windows, and retention. Keep the Cheatsheet nearby when comparing query shape and failure signals. The Practice Reference turns the ideas into a tiny local dataset, and the Exercise asks the database to prove that the model answers the question you actually asked. That distinction saves a surprising amount of expensive enthusiasm.