TimescaleDB

TimescaleDB is not a separate database. It is a PostgreSQL extension that adds the machinery time-series workloads need, which means it inherits PostgreSQL’s whole operational model: streaming replication, logical replication, pg_dump, Point-in-Time Recovery, connection pooling, and every tool that speaks the wire protocol. The extension is the product, and understanding that framing explains both what it can do and where it cannot go.

Hypertables and chunks

A hypertable looks like an ordinary PostgreSQL table and accepts ordinary SQL. Underneath, create_hypertable() partitions it automatically into chunks along a time column (and optionally a space column such as device id). Each chunk is a real table with its own indexes.

The consequences that matter:

• Inserts stay fast because they land in the newest chunk, whose indexes fit in memory, rather than in an ever-growing monolithic index.
• Queries stay fast because the planner does chunk exclusion: a query bounded to the last hour never opens older chunks.
• Retention becomes free. DROP CHUNK 'older than 90 days' detaches whole tables instead of deleting rows - no vacuum debt, no multi-hour DELETE.

Chunk interval is set per hypertable (7 days by default). Too small and planning overhead grows; too large and exclusion loses precision.

Continuous aggregates

A continuous aggregate is a materialised view over a hypertable that TimescaleDB keeps incrementally up to date on a refresh policy - per-hour rollups recomputed as new data arrives, rather than a nightly rebuild. Queries hit the aggregate; only the boundary since the last refresh is recomputed.

This is the feature that changes the cost model of dashboards and downsampling pipelines: the expensive aggregation runs once per refresh window, not once per dashboard load. Aggregates can be refreshed in real time mode (combining materialised data with raw rows for the current bucket) or materialised-only for latency.

Compression

TimescaleDB’s columnar compression converts chunk rows into a compressed, array-based layout on a policy schedule - typically compressing chunks older than a few days while recent data stays in row form for fast inserts. Compression ratios of 90 percent and better are common on append-heavy telemetry, and compressed chunks remain queryable, though modifying compressed rows is slower than ordinary row updates.

Retention and tiering

Retention policies drop chunks older than a chosen interval on schedule - the same mechanism as a manual DROP CHUNK, automated. Combined with compression this gives the full lifecycle in configuration rather than in cron jobs: ingest into the hot chunk, aggregate into continuous aggregates, compress after the window closes, drop after the retention horizon.

What being an extension costs

• Version coupling. A TimescaleDB release supports a bounded set of PostgreSQL majors, and a PostgreSQL upgrade must fit inside that window. Upgrading either side means checking the other.
• Single writer. Distributed hypertables and multi-node were removed in the 2.14 line; scale-out for writes is no longer a TimescaleDB feature. Read scaling still comes from ordinary PostgreSQL streaming replicas.
• Licence split. Core features are Apache 2.0; advanced features - compression, continuous aggregates, and the enterprise tooling around them - sit under the source-available Timescale License, which restricts offering it as a competing service. Running it yourself is unaffected.

What actually breaks

• Queries that do not constrain the time column get no chunk exclusion and scan everything.
• VACUUM and ANALYZE debt on the newest chunk shows up exactly as it does on any busy PostgreSQL table.
• Continuous aggregate refresh lag: the aggregate looks stale when the refresh job is backed up, and the fix is in the job, not the query.
• Assuming multi-node exists. Architectures designed around distributed hypertables from older documentation no longer have a migration path in current releases.

Where TimescaleDB is the wrong choice

If the workload is not time-partitioned, hypertables add machinery for nothing - plain PostgreSQL partitioning covers the general case. If the volume needs write scale-out across nodes, the honest answer is a system designed for it - Cassandra or ClickHouse - not a single-writer extension. And if the data is not PostgreSQL-shaped, forcing it through an extension buys constraints, not capabilities.