TimescaleDB in 2026: 90% Compression, Full SQL, One Big Asterisk

Picture this: you're the platform lead at a metering company with 400,000 IoT devices reporting every 15 seconds. That's roughly 2.3 billion rows a month. Your PostgreSQL instance on AWS RDS is closing in on 3 TB, autovacuum can't keep up, and your analytics team just flagged that the "energy usage by region" dashboard now takes 40 seconds to render. You've got two options: split your stack and bolt on a separate time-series database, or put up with the slowdowns until the next hardware bump.

This is the exact scenario TimescaleDB was built for. It's not a standalone database — it's a PostgreSQL extension that turns your existing Postgres into a purpose-built time-series store. You keep your relational data, your SQL, your ORM, and your BI tooling. You gain chunked hypertables, aggressive columnar compression, and pre-computed aggregates. If your organization already lives in the Postgres world, that's a massive head start over migrating to InfluxDB or QuestDB.

But there's a catch, and it's a meaningful one. Timescale officially wound down its self-managed multi-node story, betting instead on single-node deployments plus object-storage tiering. For a lot of teams that's fine. For a few, it's a dealbreaker. Below is the full teardown — what works, what's overhyped, and what it'll actually cost you over three years.

---

What TimescaleDB Actually Does

TimescaleDB is not a fork or a "NewSQL" upstart. It's a shared library that statically links into PostgreSQL and registers itself as an extension. You run CREATE EXTENSION timescaledb, and Postgres gains time-series superpowers on top of its normal transactional behavior.

Hypertables: Partitioning You Never Think About

The core abstraction is the hypertable — a logical table that Postgres transparently splits into physical "chunks" based on a time column. A standard Postgres table with 2 billion rows builds monstrous indexes and thrashes the buffer cache. A hypertable with the same data splits those rows into chunks (say, one per day or per week), and queries that filter by time only touch the relevant chunks.

In practice, this means your WHERE ts > now() - interval '30 days' queries scan 30 chunks instead of a 2-billion-row monster. You still write ordinary INSERT and SELECT statements. You don't manage partitions manually.

The magic is the chunk interval. Too small and you explode your table count. Too large and you lose chunk pruning benefits. Timescale's set_chunk_time_interval() lets you tune based on data volume — I usually start with a target of 2-4 million rows per chunk.

Continuous Aggregates: Materialized Views That Refresh Themselves

Raw telemetry is great for point queries and miserable for dashboards. A GROUP BY time_bucket('1 minute', ts) over 60 days of data is expensive no matter how you slice it.

Continuous aggregates solve this by pre-computing bucketed results in the background. You define a materialized view that buckets 1-second data into 1-minute or 1-hour summaries, set a refresh policy, and Timescale keeps the rollup fresh. Queries against the aggregate run in milliseconds because they touch pre-computed rows, not raw chunks.

The real-time refinement layer matters here. By default, timescale continuous aggregates include the "recent" data that has arrived since the last refresh, so you're never reading stale results. Refresh policies are declarative — you create the policy, and the background workers handle the rest.

Compression: The 90% Claim Is Real

This is the feature that sells executives. TimescaleDB's native compression converts hot row-based chunks into a columnar format. Numeric time-series data with repeating patterns routinely compresses 90-95%. One customer I worked with shrunk a 1.2 TB metrics database to 140 GB — no schema changes, no application changes.

Compression is enforced per-chunk via a policy (e.g., compress chunks older than 7 days). Query performance on compressed data is usually better than uncompressed for analytical queries, because the columnar layout only reads relevant columns. There are trade-offs: compressed chunks are read-only, and UPDATE/DELETE on them is either blocked or triggers decompression. Timescale supports but also throttles decompression for rare row-level edits (like purge requests under GDPR). Plan for that.

Hyperfunctions: Time-Series Math Without the Boilerplate

Time-series analytics need more than AVG and COUNT. Timescale's hyperfunctions package includes:

• time_bucket() and time_bucket_gapfill() — bucketing with gap filling for irregular data
• first() and last() — the first/last value within a bucket, far saner than the DISTINCT ON hack
• lttb() — Largest-Triangle-Three-Buckets downsampling for rendering charts
• time_weight() — proper time-weighted averages (critical for energy billing, where value persists between samples)
• stats_agg() — bulk statistical aggregates without rescanning

Gap filling deserves extra credit. IoT devices sleep, networks drop packets, and your data stream has holes. time_bucket_gapfill with locf() (last-observation-carried-forward) or linear interpolation closes those gaps without a procedural table. That's genuinely hard to build in stock Postgres.

Retention Policies and Tiered Storage

Time series is a hoarder's dilemma. You need every data point for 30 days, but you only need 1-minute summaries after a year.

Timescale handles this two ways. Retention policies drop chunks older than a threshold — a metadata operation, not a DELETE FROM ... WHERE disaster. Tiered storage moves cold chunks to object storage (S3 or compatible), where they remain queryable but cost a fraction of hot EBS.

This hot/warm/cold separation is where Timescale's strategy has landed after dropping multi-node: keep the single primary node small, archive the long tail. For many workloads it's a trade you can live happily with.

---

Pricing Breakdown

Pricing is where you need to stay alert. Timescale has three editions for self-hosting and one managed cloud product, plus a support-tier system for enterprise customers. Prices below were verified June 2026 and, as with all cloud pricing, can change without a blog post to warn you.

Self-Hosted Editions (Free, but with a License Asterisk)

A common point of confusion: the Apache 2.0 OSS edition is degraded relative to what the website demos show. New features — the interesting hyperfunctions, enhanced compression controls — ship in the TSL edition first, and some never land in Apache-licensed code. The terms allow Timescale to snap closed-source pieces onto an open-source core. That's a legitimate concern if your legal team demands pure OSS.

Timescale Cloud

Cloud pricing runs on compute + storage + networking. The free tier gives you 3 services and roughly $100-300 in trial credits (historically 30-90 days depending on promotion). Beyond that:

| Dedicated (single node) | ~$0.35/hr per vCPU (~$255/vCPU/month) | HA replicas, dedicated VMs, no noisy neighbors | HA