TimescaleDB: PostgreSQL for Time-Series — Hypertables, Compression, and the TigerData Era

What it is: TimescaleDB is a PostgreSQL extension for time-series data. You get time-series ingest and query performance while keeping full SQL, JOINs, and ACID guarantees — because it literally is Postgres underneath.

What are hypertables in TimescaleDB?

A hypertable is TimescaleDB's core abstraction: it looks and behaves like one ordinary Postgres table, but under the hood it is automatically split into "chunks" by time range (and optionally by a space key like device_id). Queries with a time filter touch only the relevant chunks, inserts always land in a small recent chunk with hot indexes, and dropping old data is a metadata operation instead of a slow DELETE.

-- A hypertable is created from a normal table
CREATE TABLE readings (
  time        TIMESTAMPTZ NOT NULL,
  device_id   INT NOT NULL,
  temperature DOUBLE PRECISION
);
SELECT create_hypertable('readings', by_range('time'));

-- Then it's just SQL — JOINs and window functions included
SELECT device_id, avg(temperature)
FROM readings
WHERE time > now() - INTERVAL '24 hours'
GROUP BY device_id;

How much compression does TimescaleDB achieve?

Typically 90-95%+ on real time-series workloads — TigerData's own benchmarks and user reports commonly show 10-20x reduction, and repetitive sensor data can exceed that. It works by converting old chunks to a columnar layout and applying type-specific codecs: delta-of-delta for timestamps, Gorilla for floats, run-length and dictionary encoding for repeating values. Compressed chunks often query faster for analytics because far fewer bytes are scanned.

ALTER TABLE readings SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);
SELECT add_compression_policy('readings', INTERVAL '7 days');

Related reading: table partitioning in SQL explains the manual version of what hypertables automate.

TimescaleDB vs InfluxDB: which time-series database?

Choose TimescaleDB if you want SQL, JOINs against relational metadata, and the Postgres ecosystem; choose InfluxDB if you want a purpose-built metrics store with simple ingest and are comfortable with its query languages (InfluxQL/SQL in v3, Flux in v2). TimescaleDB usually wins on high-cardinality data and complex analytical queries; InfluxDB is lighter to stand up for pure metrics collection. If your time-series needs to sit next to business data, Timescale's single-database story is hard to beat.

Is TimescaleDB now TigerData?

The company, yes; the extension, no. In June 2025 Timescale Inc. renamed itself TigerData, and its cloud product line is now branded around "Tiger" (Tiger Cloud/Tiger Postgres). The open-source PostgreSQL extension is still called TimescaleDB, still Apache-2.0 (core) with additional features under the Timescale License, and still actively developed. Practical upshot: docs and pricing pages may redirect to tigerdata.com, but your CREATE EXTENSION timescaledb; doesn't change.

What It Does Best

Full SQL support. Unlike purpose-built time-series databases, you keep all PostgreSQL features. JOINs, CTEs, window functions.

Automatic partitioning. Hypertables automatically partition by time. Query optimization and data management handled.

Compression. Native columnar compression. 90%+ compression ratios on time-series data.

Key Features

Hypertables: Automatic time-based partitioning at scale

Compression: Native columnar compression for old data (delta, Gorilla, dictionary codecs)

Continuous aggregates: Materialized rollups that refresh incrementally

Data retention: Automatic data lifecycle management with drop policies

Full PostgreSQL: All Postgres features plus time-series optimizations

Pricing

Open Source: Free — Apache 2.0 core, extra features under the free-to-use Timescale License (self-hosted)

Tiger Cloud (formerly Timescale Cloud): Usage-based compute + storage, ~$0.007/hour entry compute; 30-day free trial

Self-hosted: Free on your own PostgreSQL instance

When to Use It

✅ Time-series + relational data together

✅ Need SQL and existing PostgreSQL ecosystem

✅ IoT, metrics, financial tick data

✅ Already using PostgreSQL

✅ High-cardinality series (many devices/tags)

When NOT to Use It

❌ Extreme write throughput on minimal hardware (InfluxDB purpose-built)

❌ Don't need SQL (InfluxDB simpler for pure metrics)

❌ Multi-model data (consider Couchbase)

❌ Short-lived metrics scraping (Prometheus is the standard)

❌ Not already on PostgreSQL and unwilling to learn it

Common Use Cases

IoT analytics: Sensor data with device metadata in relational tables

Financial data: Tick data with reference data lookups

Monitoring: Application metrics combined with config data

Industrial data: Equipment telemetry with asset management

Energy/utilities: Smart meter data at scale

TimescaleDB vs Alternatives

vs InfluxDB: TimescaleDB has full SQL and relational JOINs; InfluxDB simpler for pure metrics ingest

vs PostgreSQL: TimescaleDB adds partitioning, compression, and rollups — often 10x+ faster on time-series queries than vanilla Postgres

vs Prometheus: TimescaleDB for long-term storage and analytics; Prometheus for pull-based metrics scraping and alerting

Unique Strengths

PostgreSQL compatibility: Full SQL with time-series performance

Relational + time-series: JOIN time-series with reference data easily

Ecosystem access: Use all PostgreSQL tools and extensions

Compression: Store 10-20x more data than vanilla Postgres

Visit TimescaleDB (TigerData) →

← Back to Data Management Tools