A time-series database is built for data points that each carry a timestamp: application and infrastructure metrics, sensor and IoT readings, and financial ticks. InfluxData’s site defines time-series data as “measurements or events that are tracked, monitored, downsampled, and aggregated over time,” and frames the time dimension as the organizing principle of the whole system rather than just another column. Data overwhelmingly arrives in time order and is queried by time range, which shapes how these databases are designed.
That shape favors a few specific operations. Writes are almost always appends of new, recent points, so the storage engine is tuned for very high ingest rates. Reads are usually time-window queries, asking what happened over the last hour, day, or month, often combined with aggregation. To keep this efficient, time-series systems lean on compression of repetitive timestamped values and on storage layouts that make scanning a contiguous slice of time cheap.
Two features that distinguish time-series databases from general-purpose stores are downsampling and retention policies. Downsampling rolls fine-grained raw points up into coarser summaries, for example turning per-second readings into per-minute averages, so long-term history stays queryable without keeping every original point. Retention policies automatically expire old data after a configured age, which matters because metric and sensor streams would otherwise grow without bound.
InfluxDB is one widely used example, and the documentation describes its model of measurements, tags, and fields with nanosecond-precision timestamps. Other systems in the category include Prometheus, common for monitoring, and TimescaleDB, which adds time-series optimizations on top of a relational engine.