Time-Series Database

In Turkish: Zaman Serisi Veritabanı

Updated September 30, 20262 min read

In short

A time-series database is a database optimized for storing and querying timestamped measurements, such as sensor readings or server metrics, in time order.

What is a time-series database?

A time-series database stores data points that each have a timestamp, one or more values, and labels, often called tags, that identify the source, such as host=web-1 and metric=cpu_usage. This kind of data arrives constantly, is almost always appended rather than updated, and is nearly always queried by time range.

To handle millions of points per second, these databases split storage into chunks by time and compress data aggressively, for example by storing only the small differences between consecutive timestamps. They include functions for downsampling, which rolls raw points up into averages per minute or hour, as well as rates, percentiles, and gap filling. Retention policies automatically delete or summarize old data. Examples include Prometheus, a monitoring system with a built-in time-series store, InfluxDB, and TimescaleDB, an extension for PostgreSQL.

A time-series database works like a ship's logbook or a heart-rate monitor: new entries are only ever added at the end, and the usual question is what happened between two points in time. It is used for infrastructure monitoring and observability metrics, Internet of Things sensors, financial market ticks, energy meters, and product analytics.

People often ask why they can't just put timestamps in a normal relational table. For small volumes you can, but a time-series database handles very high write rates and long histories far more cheaply thanks to time partitioning, compression, and automatic retention. It also differs from a data warehouse, which serves broad business analytics across many dimensions, and from log storage, which keeps text events rather than numeric measurements.

Key takeaways

Each data point has a timestamp, values, and identifying tags.
Data is mostly appended and queried by time range.
Time partitioning and compression keep huge volumes cheap to store.
Downsampling and retention policies manage old data automatically.
High cardinality, meaning too many unique tag combinations, is a common performance problem.

Example

Querying time-series data with SQL (PostgreSQL syntax)sql

-- One row per measurement: when, from where, and the value
CREATE TABLE cpu_usage (
  time  TIMESTAMPTZ NOT NULL,
  host  TEXT NOT NULL,
  usage DOUBLE PRECISION
);

-- Average CPU per host for each minute of the last hour
SELECT host, date_trunc('minute', time) AS minute, avg(usage) AS avg_usage
FROM cpu_usage
WHERE time > now() - INTERVAL '1 hour'
GROUP BY host, minute
ORDER BY minute;

Readers ask

Can I use PostgreSQL as a time-series database?

Yes, for moderate volumes a regular table with an index on the timestamp works well. For very high write rates, extensions or dedicated time-series databases add automatic partitioning, compression, and retention.

What is downsampling?

Downsampling replaces many detailed data points with fewer summary points, such as one average per hour instead of one reading per second. It keeps long histories small while preserving the overall trend.

What is high cardinality in a time-series database?

Cardinality is the number of unique series, meaning unique combinations of metric name and tag values. Tags with many possible values, such as user IDs, create huge numbers of series and can slow down or overload the database.