What Is a Time-Series Database: TimescaleDB, InfluxDB and More

The short answer

A time-series database (TSDB) stores measurements tied to a timestamp: sensor readings, server CPU load, exchange rates, orders per minute. Such data has a predictable shape, and TSDBs are built around it: fast writes of new points, fast queries over time ranges, automatic deletion of old data and pre-computed aggregates.

You do not need one from day one. A well-indexed PostgreSQL table handles a lot. A TSDB pays off when the data keeps growing, raw points must be kept for a limited time and dashboards need minute, hour and day rollups.

What makes time-series data special

• Append-only. New points are added constantly; old points are rarely updated.
• Time-based queries. Almost every query is "for this device / metric, over this period, grouped by interval".
• Retention. Raw data loses value with age. Keeping second-level readings for years is expensive and often useless.
• Downsampling. Old data is kept as aggregates: averages, minimums and maximums per minute or hour instead of every point.
• High cardinality risk. Every unique combination of labels (device, region, customer) creates a separate series. Too many combinations slow most TSDBs down.

When a regular PostgreSQL table is enough

If you have a moderate number of devices or metrics and queries are simple, start with:

CREATE TABLE readings (
  device_id  integer      NOT NULL,
  ts         timestamptz  NOT NULL,
  temperature numeric(5,2),
  PRIMARY KEY (device_id, ts)
);
-- for append-only data in time order, a compact BRIN index helps range scans
CREATE INDEX readings_ts_brin ON readings USING brin (ts);

Add declarative partitioning by time (for example, monthly partitions) when the table grows: dropping an old partition is much cheaper than a large DELETE. Signals that you have outgrown this setup: partition management turns into manual work, rollup queries become slow, storage grows faster than you can afford.

The main options

TimescaleDB

A PostgreSQL extension. Tables become hypertables that are automatically split into time chunks. It adds compression, retention policies and continuous aggregates (materialized rollups that update incrementally). You keep full SQL, joins with ordinary business tables, and the PostgreSQL tooling you already know. Some features are distributed under the vendor's own license, so check the terms for your hosting setup.

InfluxDB

A purpose-built TSDB with its own data model: measurements, tags (indexed labels) and fields (values). Writing data is simple, retention is built in, and there is a large ecosystem of collectors, especially Telegraf. The query language has changed between major versions, so check which one your version uses before building on it.

ClickHouse

A columnar analytics database, not a TSDB by name, but very strong for large volumes of events and metrics. Tables partitioned by time, TTL rules for deletion and materialized views for rollups cover typical time-series needs. It is excellent at scanning and aggregating billions of rows; frequent updates and single-row deletes are not its strength.

Prometheus

A monitoring system with a built-in TSDB. It pulls metrics from services, stores them locally and queries them with PromQL; alerting is part of the ecosystem. Local storage is designed for operational retention; long-term storage is usually handled by remote-write backends. Its own documentation advises against using it where you need 100% accurate per-event data, such as billing.

How to choose by task

For money, store amounts in exact decimal types and keep the authoritative ledger in a transactional database; a TSDB holds the analytic copy.

Common mistakes

• Using user IDs or request IDs as labels and exploding cardinality.
• Keeping raw data forever without a retention and downsampling plan.
• Choosing a separate TSDB when the real need is one extra index in PostgreSQL.
• Treating Prometheus metrics as exact business records.