Cloud Parts

TimescaleDB

A PostgreSQL extension that turns ordinary tables into time-partitioned, compressed time-series tables.

What it is
Time-series databases
Type
Open source
Made by
Tiger Data (formerly Timescale)
License
Apache 2.0 (core) and Tiger Data License (full Community Edition)
Facts checked
5 October 2026
Website Source code

What it is

TimescaleDB is not a separate database. It is an extension you load into PostgreSQL, so you keep SQL, joins with your other tables, transactions, existing drivers and tools. You mark a table as a hypertable, and behind the scenes it splits rows into chunks by time, seven days each by default. Inserts land in the newest chunk, queries skip chunks outside their time range, and dropping old data means dropping whole chunks instead of deleting rows one by one.

Older chunks can be converted to a columnstore, which groups values by column and compresses them, so scans over long periods read far less data. Continuous aggregates keep rollups such as hourly averages up to date as new rows arrive, and background policies handle compression and retention on a schedule. These features belong to the Community Edition under the Tiger Data License, which is free to self-host but may not be offered as a hosted service. The Apache 2.0 edition has only the basics, such as hypertables. The company behind it renamed itself from Timescale to Tiger Data in June 2025 and runs the hosted Tiger Cloud.

Why teams pick it

  • It’s still PostgreSQL: full SQL, joins with business tables, and the same backups and tools
  • Automatic time partitioning with cheap chunk-level retention
  • Columnstore compression and continuous aggregates keep long-range queries fast
  • New syntax (since 2.20) makes a hypertable with plain CREATE TABLE ... WITH (tsdb.hypertable)

Watch out for

  • Columnstore, continuous aggregates and retention policies need the Tiger Data License edition, so managed Postgres services that ship only the Apache edition lack them
  • Writes scale up on one PostgreSQL primary rather than out across many nodes
  • You still operate PostgreSQL underneath: connections, vacuum, upgrades and extension versions

Alternatives

What all time-series databases have in common →
Amazon TimestreamAWSAWS’s time-series databases: a serverless engine now closed to new customers, and managed InfluxDB 2 and 3.Apache IoTDBOpen sourceAn Apache time-series database for industrial IoT that stores everything in its own open file format, TsFile, and lets you model devices as a tree of paths or as SQL tables.+1 TimechoDBArcOpen sourceA young single-binary time-series database in Go that writes incoming data as Parquet files and queries them with DuckDB SQL.ArcticDBCommercialMan Group’s serverless DataFrame database: a Python library with a C++ engine that stores versioned pandas DataFrames directly in S3, Azure Blob Storage or local LMDB.GreptimeDBOpen sourceA Rust database that stores metrics, logs and traces as tables on object storage, queried with SQL or PromQL.InfluxDBOpen sourceThe best-known time-series database, fed by line protocol and Telegraf; now in its third generation, a Rust rewrite that keeps data as Parquet files on object storage.kdb+CommercialA columnar time-series database that is also an interpreter for q, an array language, used for market data across trading and risk.QuestDBOpen sourceA columnar time-series database in Java, C++ and Rust that ingests millions of rows a second and answers time-series SQL, with old partitions kept as Parquet.TDengineOpen sourceA clustered time-series database for IoT and industrial data that gives every device its own table, grouped under “supertables” with tags.Workers Analytics EngineCommercialCloudflare’s time-series analytics store for Workers: a non-blocking `writeDataPoint()` call to record events with unlimited cardinality, adaptive sampling to keep it cheap, and a SQL API to query them.

How it fits with other technologies

A hypertable with columnstore and retention policies · sql

CREATE TABLE readings (
  time    timestamptz NOT NULL,
  well_id int NOT NULL,
  psi     double precision
) WITH (tsdb.hypertable, tsdb.segmentby = 'well_id', tsdb.orderby = 'time DESC');

-- since 2.23 this also adds a columnstore policy: chunks convert after one chunk interval (7 days)
SELECT add_retention_policy('readings', drop_after => INTERVAL '2 years');

SELECT time_bucket('15 minutes', time) AS bucket, well_id, max(psi)
FROM readings
WHERE time > now() - INTERVAL '1 day'
GROUP BY bucket, well_id ORDER BY bucket;

See it in a real stack

IoT telemetry pipeline →
Live model
What you’re watchingDevice readings append to a Kinesis stream. Lambda reads small batches into TimescaleDB, where Grafana’s dashboard queries find them. A second consumer archives the stream to S3 in large, infrequent batches.

Benchmarks

Benchmark · ClickHouse Inc.ClickBenchHow fast analytical databases run 43 SQL queries over one 100-million-row table of web analytics events, on the same cloud machines.Includes TimescaleDB · 7 caveats to read firstBenchmark · Tiger Data (formerly Timescale)Time Series Benchmark Suite (TSBS)A Go toolkit that generates synthetic server-monitoring or IoT time series, bulk-loads it into a database and times a fixed set of time-series queries.Includes TimescaleDB · 6 caveats to read first
How to read a benchmark →
Where it came from2017–2025

Ajay Kulkarni and Mike Freedman first ran iobeam, an Internet of Things data platform. It collected time-series data from more than 100,000 devices, and the off-the-shelf time-series databases they tried didn’t meet their needs. The usual advice was that relational databases couldn’t scale to time-series volumes, which is why NoSQL time-series stores existed, but those stores gave up the secondary indexes, rich queries and joins that made SQL useful.

So they built time-series storage on top of PostgreSQL instead. People took an interest in the database before the company changed course, and in early 2017 the founders relaunched it as Timescale. Kulkarni announced TimescaleDB on April 4, 2017, and two weeks later Freedman took a “somewhat heretical stance”: that relational databases can be quite powerful for time-series data, if you solve the scaling problem. TimescaleDB 1.0 followed in October 2018.

In December 2018 Timescale began splitting features between an Apache 2.0 core and a source-available Timescale License that bars offering them as a hosted database service, aimed at cloud vendors who sell open-source software without funding it. Native compression arrived in 2019. In June 2025 the company renamed itself Tiger Data, keeping the TimescaleDB name for the extension.

Why it’s built this way

An extension inside PostgreSQL, not a new database
Users keep full SQL, joins with their business tables, and every existing driver and tool. The founders were frank that “PostgreSQL was the only database that we wanted to use.”
Chunks by time, sized to fit in memory
A plain table slows down once its indexes outgrow RAM, because each insert may read and write 8 KB pages on disk. Time-series inserts land mostly in the latest interval, so splitting by time keeps the active chunk and its indexes in memory.
Keep B-tree indexes instead of LSM trees
NoSQL time-series stores used log-structured merge trees for fast writes, at the cost of more memory and weak secondary indexes. Chunking let TimescaleDB keep PostgreSQL’s ordinary indexes and still sustain high insert rates.
Columnar compression per chunk
Old chunks are rarely updated, so 1.5 began rolling their rows into per-column arrays compressed with type-specific methods, such as delta-of-delta for timestamps and Gorilla compression for floats.

Timeline

  1. 2017

    iobeam relaunches as Timescale; TimescaleDB announced in April

  2. 2018

    Version 1.0 in October; Timescale License introduced in December

  3. 2019

    1.5 adds native columnar compression

  4. 2020

    Timescale License revised to grant rights to modify and repair

  5. 2025

    Timescale renames itself Tiger Data in June

Sources10 · facts checked 5 October 2026

Improve this page on GitHub