QuestDB vs TimescaleDB

Quick verdict

This page is for engineers choosing a SQL store for sensor, meter or equipment telemetry who have narrowed the field to two PostgreSQL-flavoured options. Both speak SQL and both accept PostgreSQL drivers, but one is PostgreSQL and the other only talks its wire protocol. For the background on time-series storage, start with the time-series and IoT data hub.

QuestDB describes itself as an open source time-series database engineered for low latency. It stores each column in its own files inside time partitions, sorts every table by a designated timestamp, and compiles filters with a JIT compiler. QuestDB Open Source is under the Apache License 2.0, and QuestDB Enterprise builds on the same core. The latest release on GitHub when checked was 10.1.0 (22 October 2026). See the QuestDB guide.

TimescaleDB, from Tiger Data (formerly Timescale), is a PostgreSQL extension. A hypertable looks like one table but is split automatically into time chunks; older chunks can be converted to the hypercore columnstore, continuous aggregates keep roll-ups current, and retention policies drop whole chunks. The latest release when checked was 2.31.0 (20 October 2026). See the TimescaleDB guide.

Side by side

Key differences

A separate engine versus PostgreSQL itself

The deepest difference is what you operate. TimescaleDB is PostgreSQL with an extension: one server holds telemetry and business tables, so a single query can join hourly chiller roll-ups to open work orders, and roles, backups, replication and monitoring are PostgreSQL's. The cost is that you run PostgreSQL (vacuum, connection pooling, upgrades of both PostgreSQL and the extension).

QuestDB is a separate server designed only for time-series tables. Its PostgreSQL wire protocol is the recommended way to query, so PostgreSQL drivers and many tools connect, but compatibility is partial: the documentation names SSL, COPY FROM STDIN and DELETE statements among unsupported features, and it is not a transactional database for records such as work orders. In our view that makes QuestDB a second database next to your relational system of record, not a replacement for it.

Time-series SQL: built-in operators versus PostgreSQL plus hyperfunctions

QuestDB adds keywords for common time-series questions, all of which need a designated timestamp: SAMPLE BY buckets rows by time with FILL for empty buckets, LATEST ON ... PARTITION BY returns the latest row per series, and ASOF JOIN attaches the most recent matching row from another table, such as the calibration or tariff in force at each reading.

TimescaleDB keeps PostgreSQL SQL and adds functions such as time_bucket. Latest-per-series is DISTINCT ON or a lateral join, and an as-of lookup is a LEFT JOIN LATERAL ... ORDER BY ... LIMIT 1, which the QuestDB guide shows running on plain PostgreSQL. The same 15-minute question in each dialect:

-- Illustrative, not run here: QuestDB syntax from the QuestDB documentation;
-- check it against the documentation for your version before use.
SELECT ts, sensor_id, avg(ppm) AS avg_ppm
FROM zone_co2
WHERE ts >= '2026-11-06' AND ts < '2026-11-07'
SAMPLE BY 15m FILL(PREV);

-- Illustrative, not run here: TimescaleDB syntax from the Tiger Data documentation;
-- check it against the documentation for your version before use.
SELECT time_bucket(INTERVAL '15 minutes', ts) AS bucket, sensor_id, avg(ppm) AS avg_ppm
FROM zone_co2
WHERE ts >= '2026-11-06' AND ts < '2026-11-07'
GROUP BY bucket, sensor_id
ORDER BY bucket, sensor_id;

The QuestDB form fills empty buckets with the previous value; the TimescaleDB form above returns only buckets that have rows (TimescaleDB documents separate gap-filling functions). In our view, QuestDB's operators are shorter for these specific questions, while TimescaleDB gives you the whole of PostgreSQL SQL, including window functions, CTEs and joins to any table.

Ingestion, duplicates and corrections

QuestDB ranks its write paths: its own client libraries over the binary QuestDB Wire Protocol (QWP) first, the InfluxDB line protocol over HTTP or TCP for existing collectors such as Telegraf, and SQL INSERT over PGWire for lower volumes. Partitioned tables use a write-ahead log for concurrent writers, and out-of-order rows rewrite only the partitions they touch. Duplicates are handled by declaring DEDUP UPSERT KEYS, for example on (ts, sensor_id), so a replayed gateway buffer does not add rows. QuestDB reports a peak of 19 million rows per second per instance, measured by QuestDB on version 10.0 over QWP; that is a vendor figure, not an independent result.

TimescaleDB takes writes from any PostgreSQL client; the documentation recommends multi-row INSERT or COPY for high volumes, and throughput depends on batching and PostgreSQL tuning. Corrections are ordinary UPDATE, DELETE or upserts against a primary key, and the documentation says the columnstore accepts them without a manual decompress step. If readings are regularly corrected or deleted after the fact, that is a point for TimescaleDB; see late-arriving and out-of-order data.

Storage, roll-ups and retention

Both drop old data by whole time ranges rather than row by row. QuestDB sets TTL per table, dropping partitions whose whole time range has passed (QuestDB Enterprise replaces TTL with storage policies), and keeps longer-lived roll-ups in materialized views with their own TTL. Open source QuestDB can convert partitions to Parquet with ALTER TABLE; Enterprise tiers cold partitions to object storage automatically.

TimescaleDB converts older chunks to the hypercore columnstore (Tiger Data reports 90 to 98% storage reduction on its pages; measure your own ratio), keeps roll-ups in continuous aggregates that refresh incrementally and survive raw-data retention if the refresh window is set correctly, and drops chunks with add_retention_policy. Tiered storage to object storage is a Tiger Cloud feature. See retention and downsampling for the patterns.

Editions, licences and security

QuestDB: the open source engine is under the Apache License 2.0 and is a single node. Replication with automatic failover, read replicas, TLS on all protocols, single sign-on, role-based access control down to columns, audit logs, automated backups and automatic tiering are QuestDB Enterprise features. Because the open source PGWire endpoint does not support SSL, keep it on a private network or behind a TLS-terminating proxy.

TimescaleDB ships two editions from one repository. The Apache 2 Edition covers hypertables and chunks; the Community Edition, the default, adds the columnstore, continuous aggregates, retention policies and the job scheduler under the Timescale License (TSL), which Tiger Data's editions page now also calls the Tiger Data License. The TSL may be used without charge under its terms, and its section 2.2 prohibits "using any TSL Licensed Software to provide time-sharing services or database-as-a-service services". Security is PostgreSQL security: roles, grants, row-level security and TLS. Run SHOW timescaledb.license; on a managed PostgreSQL service to see which edition you have. Not legal advice: this summarises the licence texts; read them and take advice for your situation.

Pricing and licensing

QuestDB open source carries no licence fee. On 7 November 2026 the questdb.com pricing address showed the Enterprise page, with deployment listed as custom, a free Enterprise trial and "Contact Sales"; no prices were published, so none are quoted.

TimescaleDB self-hosted carries no licence fee: Tiger Data's editions page states that "TimescaleDB Community Edition is completely free if you manage your own service", subject to the TSL. Tiger Cloud lists Performance, Scale and Enterprise plans with compute billed hourly and storage metered by average GB used; the pricing page states that "Storage is priced the same across all regions, but compute prices will vary depending on the region", and offers a 30-day free trial on the Performance plan. We do not quote figures here because the compute prices depend on region and configuration; see TimescaleDB vs InfluxDB for more on the Tiger Cloud billing model. Tiger Data also sells self-managed TimescaleDB Enterprise on quote.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• Volumes are modest (as an illustrative scale, a few thousand points at 15-minute intervals): plain PostgreSQL with partitions may be enough; see TimescaleDB vs PostgreSQL.
• Your stack is built on line protocol, Telegraf and InfluxQL: see QuestDB vs InfluxDB and TimescaleDB vs InfluxDB.
• The data is infrastructure metrics for PromQL dashboards and alerts: see VictoriaMetrics vs Prometheus.
• Large analytical scans across years and many sites dominate: see ClickHouse vs TimescaleDB.

Final recommendation

Frequently asked questions

Sources

• QuestDB documentation: Introduction
• QuestDB documentation: SAMPLE BY
• QuestDB documentation: PostgreSQL Wire Protocol
• QuestDB Enterprise
• questdb repository on GitHub (README, releases)
• Tiger Data docs: Understand hypertables
• Tiger Data docs: Understand hypercore
• Tiger Data docs: Compare TimescaleDB editions
• timescaledb repository: Timescale License Agreement
• Tiger Cloud pricing

Checked November 2026.

How we research comparisons: our editorial method.