// the find
timescale/timescaledb
A time-series database for high-performance real-time analytics packaged as a Postgres extension
TimescaleDB is a PostgreSQL extension that adds hypertables, columnar storage, continuous aggregates, and time_bucket() to vanilla Postgres — making it a real time-series database without leaving the SQL ecosystem. It's for teams who have time-stamped data at serious ingestion rates (IoT, finance, SaaS metrics) and don't want to manage a separate purpose-built TSDB. If you're already on Postgres, this is the lowest-friction path to sub-second aggregations over billions of rows.
The columnar compression story is genuinely good — 90%+ compression on time-series data is realistic, not marketing, because the data is ordered and repetitive by nature. Continuous aggregates with incremental refresh beat PostgreSQL materialized views in every dimension: they refresh only the changed interval, not the full dataset, and you can stack them (aggregate of an aggregate). The upgrade path is unusually well-maintained; 130+ migration scripts in sql/updates/ covering two-way upgrades back to 2.9.x means you won't get stranded on an old version. SkipScan (visible in the README's DISTINCT ON example) is a clever planner optimization for 'latest value per series' queries that would otherwise require a sequential scan or a carefully crafted index.
The dual-license split (Apache 2.0 core, Timescale License for compression and continuous aggregates) means the features you actually want in production are not fully open source — a real constraint for anyone with OSS compliance requirements. The README is mid-rebrand chaos: it mixes 'TimescaleDB', 'Tiger Cloud', and 'Tiger Data' throughout, docs links point to two different domains, and the logo alt text says 'Tiger Data logo' while the repo is still named timescaledb. Not a code problem, but signals internal turbulence. Multi-node (distributed hypertables) was deprecated and removed, so horizontal write scaling is now only available on the managed cloud product — self-hosted deployments are single-node only. Building from source on anything other than the provided Docker image is non-trivial: it's a C extension against a specific Postgres version, and the CI matrix shows just how much version-specific pain exists across PG versions and platforms.