TimescaleDB

What it is

TimescaleDB is a PostgreSQL extension that adds first-class time-series support: automatic partitioning, continuous aggregates, and aggressive compression. It was first released in 2017 by Timescale Inc. and runs as CREATE EXTENSION timescaledb; on top of any Postgres 14+. Because it’s an extension and not a separate database, you keep all the SQL semantics, the JOIN engine, and the operational tooling — you just get faster time-series writes and queries on top.

Why people use it

• Hypertables. A hypertable looks like a regular Postgres table but is automatically partitioned by time (and optionally by space). Inserts route to the right chunk; queries prune chunks based on time predicates. You write normal SQL and don’t think about partitioning.
• Continuous aggregates. Materialized views that incrementally refresh as new data lands. The classic example: 1-minute candle bars precomputed from raw ticks, so dashboard queries scan rollups instead of raw events.
• Compression. Columnar compression of older chunks. Typical compression ratio is 10–20× on time-series workloads. You define a policy (e.g., “compress chunks older than 7 days”) and a background job handles it.
• Postgres compatibility. You can JOIN time-series data against your relational tables, use JSONB, and reuse your existing migrations, ORMs, and observability stack.

When to use TimescaleDB

• Time-series workloads where you want Postgres compatibility (monitoring, IoT, financial ticks, application metrics).
• You’re already on Postgres and don’t want to introduce a separate analytical database.
• You need to JOIN time-series data with relational data (users, devices, products).
• Workloads in the millions-to-low-billions of rows range. Beyond that, dedicated columnar engines usually win.

When not to use TimescaleDB

• Petabyte-scale time-series. ClickHouse, InfluxDB v3, or Druid handle this better.
• Pure log search. OpenSearch or ClickHouse with text indices fit more directly.
• Small datasets. If your table will only ever hold a few million rows, vanilla Postgres with a normal timestamptz index works fine. The hypertable abstraction adds complexity you won’t get back.
• Cross-shard distributed writes. Vanilla TimescaleDB is single-node. The distributed-hypertable feature was deprecated in 2024.

Notable trade-offs

• Split license. Core (Apache 2) covers hypertables and continuous aggregates. The Timescale License (TSL) covers compression, retention policies, and bottomless storage. TSL is source-available but not OSI open source — for some organizations this matters.
• Compression is one-way per chunk. Once a chunk is compressed, updates require decompressing it first. Compress only chunks that are effectively immutable.
• Continuous aggregates have refresh lag. The materialized view updates on a policy, not on every insert. Dashboards reading from continuous aggregates show data that may be N minutes behind.
• No clustering. With distributed hypertables deprecated, TimescaleDB is single-node. Vertical scale only.

Managed offering

Timescale Cloud is the managed version, with bottomless S3 storage and a free trial. Self-hosting on any Postgres 14+ is fully supported.