QuestDB vs InfluxDB for High-Frequency Telemetry

Quick verdict

This page is for engineers handling high-frequency telemetry: chiller and pump power at one-second intervals, vibration or current readings from rotating equipment, many thousands of BMS points per site, or meter data from a portfolio of buildings, where ingestion rate and recent-data queries matter most. For general design of sensor tables and how storage fits with brokers and analytics platforms, start with the time-series and IoT data hub.

QuestDB describes itself as an open source time-series database engineered for low latency. It is a standalone server with a column-oriented, time-partitioned storage engine, licensed under Apache 2.0; QuestDB Enterprise builds on the same core. The latest release on GitHub when checked was 10.1.0. The QuestDB guide explains its storage and SQL in depth.

InfluxDB 3 is InfluxData's current time-series database, written in Rust on Apache Arrow, DataFusion and Parquet. InfluxDB 3 Core is the open source release (MIT or Apache 2.0) and InfluxDB 3 Enterprise the commercial one; the latest release when checked was v3.12.1. See the InfluxDB guide for its data model and editions.

Side by side

Key differences

Data model and schema

QuestDB tables look like SQL tables with time-series rules. Every table should have a designated timestamp: rows are stored sorted by it, it cannot be NULL or updated, and it enables partitioning, SAMPLE BY, LATEST ON, ASOF JOIN, TTL and deduplication. Repeated identifiers such as chiller, site or point names go into SYMBOL columns, which are dictionary-encoded. You choose types per column (for example DOUBLE, INT, BOOLEAN, VARCHAR).

-- Illustrative DDL, not run here: adapted from the QuestDB documentation; check every
-- setting against the documentation for your version before use.
-- TTL 90 DAYS is an illustrative value: set it from how long raw readings are needed
CREATE TABLE chiller_kw (
    ts         TIMESTAMP,
    chiller_id SYMBOL,
    site       SYMBOL,
    kw         DOUBLE
) TIMESTAMP(ts) PARTITION BY DAY TTL 90 DAYS
  DEDUP UPSERT KEYS (ts, chiller_id);

InfluxDB 3 has databases, tables and columns of three kinds: time, tags and fields. Tags identify a series and form the table's primary key (with time), which also sets the sort order of its Parquet files; the first write to a table fixes the tag column order, and tag columns cannot be changed afterwards. Fields hold the measured values as float, integer, unsigned integer, boolean or string. The schema is created by writing:

# Illustrative, not run here: line protocol format from the InfluxDB 3 Core documentation
chiller_kw,site=hq,chiller_id=ch-1 kw=212.0,running=true 1793095205000000000

The same line could be sent to QuestDB, which implements the InfluxDB line protocol and creates tables and columns on first write. That makes a side-by-side trial simpler: point an existing Telegraf output at both. QuestDB now calls ILP a compatibility protocol and recommends its own QWP clients for new applications.

Time-series SQL: SAMPLE BY and LATEST ON versus DATE_BIN and caches

Both speak SQL, but with different extensions. QuestDB adds SAMPLE BY (time buckets with FILL for empty buckets, aligned to calendar boundaries by default), LATEST ON ... PARTITION BY (the latest row per series) and ASOF JOIN (the most recent matching row in another table at or before each timestamp). InfluxDB 3 SQL uses DATE_BIN for bucketing, date_bin_gapfill with interpolate or locf for gaps, and offers a Last Value Cache and Distinct Value Cache for current-state lookups; InfluxQL remains available for 1.x-style dashboards.

-- Illustrative, not run here: one-minute average and latest reading per chiller,
-- syntax from the QuestDB documentation; check it against the documentation for your version.
SELECT ts, chiller_id, avg(kw) AS avg_kw, max(kw) AS max_kw
FROM chiller_kw
WHERE ts >= '2026-10-27' AND ts < '2026-10-28'
SAMPLE BY 1m FILL(PREV);

SELECT * FROM chiller_kw LATEST ON ts PARTITION BY chiller_id;

-- Illustrative, not run here: InfluxDB 3 SQL pattern from the InfluxDB 3 Core documentation;
-- check it against the documentation for your version before use.
SELECT DATE_BIN(INTERVAL '1 minute', time, '2026-01-01T00:00:00Z'::TIMESTAMP) AS time,
       chiller_id, avg(kw) AS avg_kw, max(kw) AS max_kw
FROM chiller_kw
WHERE time >= now() - INTERVAL '1 day'
GROUP BY 1, chiller_id
ORDER BY 1;

For reference, plain PostgreSQL 14 and later has the same date_bin function, and DISTINCT ON gives the latest row per series. The queries below ran on PostgreSQL 18.6 and show what the two products' operators compute, without their storage optimisations:

-- Plain PostgreSQL (run on PostgreSQL 18.6, PGlite)
CREATE TABLE chiller_kw (
    chiller_id text        NOT NULL,
    ts         timestamptz NOT NULL,
    kw         double precision NOT NULL,
    PRIMARY KEY (chiller_id, ts)
);

INSERT INTO chiller_kw VALUES
    ('ch-1', '2026-10-27 10:00:05+00', 212.0),
    ('ch-1', '2026-10-27 10:00:35+00', 215.5),
    ('ch-1', '2026-10-27 10:01:05+00', 219.0),
    ('ch-1', '2026-10-27 10:01:35+00', 221.5),
    ('ch-2', '2026-10-27 10:00:10+00', 180.0),
    ('ch-2', '2026-10-27 10:01:10+00', 184.0);

SELECT date_bin('1 minute', ts, '2026-01-01 00:00+00') AS minute,
       chiller_id, round(avg(kw)::numeric, 2) AS avg_kw, max(kw) AS max_kw
FROM chiller_kw
GROUP BY 1, chiller_id
ORDER BY 1, chiller_id;

         minute         | chiller_id | avg_kw | max_kw
------------------------+------------+--------+--------
 2026-10-27 10:00:00+00 | ch-1       | 213.75 |  215.5
 2026-10-27 10:00:00+00 | ch-2       | 180.00 |    180
 2026-10-27 10:01:00+00 | ch-1       | 220.25 |  221.5
 2026-10-27 10:01:00+00 | ch-2       | 184.00 |    184

SELECT DISTINCT ON (chiller_id) chiller_id, ts, kw
FROM chiller_kw
ORDER BY chiller_id, ts DESC;

 chiller_id |           ts           |  kw
------------+------------------------+-------
 ch-1       | 2026-10-27 10:01:35+00 | 221.5
 ch-2       | 2026-10-27 10:01:10+00 |   184

QuestDB's ASOF JOIN is useful for attaching the calibration, setpoint or tariff in force at each reading. The InfluxDB 3 Core SQL join reference we checked lists INNER, LEFT, RIGHT and FULL joins and does not describe an ASOF JOIN. Its locf function carries the last observed value forward, but only into empty date_bin_gapfill buckets of the same query, which is not an as-of lookup into another table. A workaround with ordinary joins or subqueries may be possible in InfluxDB 3 SQL, but we did not find one documented; check the SQL reference for your version. The QuestDB guide shows it alongside a PostgreSQL LATERAL equivalent.

Ingestion, duplicates and late data

QuestDB offers three write paths: its client libraries over the binary QuestDB Wire Protocol (QWP), the InfluxDB line protocol over HTTP (recommended) or TCP, and SQL INSERT over PGWire for lower volumes. Partitioned tables use a write-ahead log by default, which supports concurrent writers and merges out-of-order rows; out-of-order data only rewrites the partitions it touches. Deduplication is declared on the table: with DEDUP UPSERT KEYS (ts, chiller_id) a replayed reading replaces the stored one, and an identical row is skipped.

InfluxDB 3 accepts line protocol over HTTP and is compatible with the 1.x and 2.x write APIs, so existing clients and Telegraf work. A point is identified by its table, tag set and timestamp; writing the same point again merges field sets, but when duplicate writes set the same field, InfluxDB does not guarantee which value is kept. Replays of identical data are therefore harmless, while corrections that rely on overwriting need care. Row-level delete is listed as a coming Enterprise feature.

For gateways that buffer during network outages, both need idempotent writes and a plan for late data; see duplicate telemetry events and late-arriving and out-of-order data. In the architecture these pages assume, the MQTT broker or Kafka moves and buffers the messages, the database stores and queries them, and a warehouse or lakehouse handles long-range analytics joined with CAFM and CMMS data.

Retention and storage tiers

QuestDB sets retention per table with TTL, which drops partitions whose whole time range is older than the window; partition size (HOUR to YEAR) is chosen from the row rate, with the documentation suggesting 30 to 80 million rows per partition for average-sized rows. Open source QuestDB can convert partitions to Parquet with ALTER TABLE; QuestDB Enterprise converts cold partitions automatically and tiers them to object storage, and replaces TTL with storage policies.

InfluxDB 3 sets retention per database, and by default data does not expire. In Core the retention period can only be set when the database is created, so raw high-frequency data and long-lived roll-ups usually go into separate databases with different retention. Parquet files can live on object storage (S3, Azure, GCS) from the start. InfluxDB documents Core as purpose-built for real-time monitoring and recent data, with historical query capability added in Enterprise. See retention and downsampling for roll-up patterns.

Performance: what the vendors say

QuestDB reports a peak ingestion of 19 million rows per second per instance, measured by QuestDB on version 10.0 over QWP and published in its GitHub README. InfluxData reports query response times under 10 ms for last-value queries and 30 ms for distinct metadata in InfluxDB 3 Core. These are vendor figures on vendor-chosen hardware and data, they measure different things, and neither is evidence that one product is faster than the other for your workload.

On design rather than measurement: QuestDB's architecture page describes a SQL parser, a just-in-time (JIT) compiler and a vectorised execution engine that "process data in table page frames for better CPU use"; InfluxDB 3 offers Last Value and Distinct Value caches for current-value lookups and persists Parquet files to local disk or object storage. Neither description says how either product will perform on your data. Test with your real point count, write batch size, out-of-order rate and the queries your dashboards run; the ingestion benchmarking guide and time-series database performance explain how to keep that fair.

Editions, licences, security and operations

Both open source editions are single nodes, and both vendors put high availability in Enterprise. QuestDB Enterprise adds 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 tiered storage. The open source PGWire endpoint does not support SSL, so keep it on a private network or behind a TLS-terminating proxy.

InfluxDB 3 Enterprise adds high availability, read replicas and historical query capability, and resource tokens that grant permissions on specific databases. The InfluxDB 3 Enterprise documentation page we checked is not consistent on security: its feature list still shows "Enhanced security (coming soon)" (and row-level deletes as coming soon), while the InfluxDB 3 Enterprise 3.12 announcement on the same page says "User authentication and RBAC are generally available." We cannot tell from the documentation which statement reflects your version, so check the release notes and security documentation for the version you run. InfluxDB 3 Core runs with token authentication by default, but its admin tokens grant access to every action on the server, so give applications their own network path and rotate tokens. For either product, back up and test restores, and size storage from series count, sample rate and retention; see storage sizing for sensor telemetry.

Licences. The QuestDB repository's LICENSE.txt is the Apache License 2.0, whose section 2 grants "a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form", subject to its conditions, including those on redistribution in section 4. The InfluxDB repository states: "The open source software we build is licensed under the permissive MIT or Apache 2 licenses at the user's choosing." (texts in LICENSE-MIT and LICENSE-APACHE). QuestDB Enterprise is sold by QuestDB through its Enterprise page; InfluxDB 3 Enterprise runs under a licence from InfluxData, and its licence page lists Trial, At-Home and Commercial licences. Not legal advice: this is a factual summary of the licence texts as published on 27 October 2026; read the licences for the versions you use and take legal advice for your situation.

Pricing and licensing

QuestDB open source is under the Apache License 2.0 and carries no licence fee. On 27 October 2026 the questdb.com pricing address redirected to the Enterprise page, which offers a free Enterprise trial and pricing through sales for cloud, on-premises, hybrid and bring-your-own-cloud deployment; no self-service price list was published, so we quote no prices.

InfluxDB 3 Core: InfluxData's pricing page states that it "is open source and free to download and run with no license required". InfluxDB 3 Enterprise is priced by CPU configuration through sales, with a 30-day free trial. InfluxDB Cloud Serverless is usage-based with a free tier limited to 30-day retention, and Cloud Dedicated is custom-priced; the pricing page lists Serverless unit prices without stating a region, so we do not quote them (see TimescaleDB vs InfluxDB for the pricing model).

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

Where each one leads

Limitations

When to choose each

When neither is right

• Telemetry must be joined to assets and work orders in a relational database: see TimescaleDB vs InfluxDB.
• The data is infrastructure metrics for alerting: see InfluxDB vs Prometheus.
• Large-scale analytical queries across years and many sites dominate: see ClickHouse vs TimescaleDB and ClickHouse vs PostgreSQL.
• You are still shortlisting engines: see the time-series database selection guide.

Final recommendation

Frequently asked questions

Sources

• QuestDB documentation: Introduction
• QuestDB documentation: Architecture
• QuestDB documentation: Designated timestamp
• QuestDB documentation: Time partitions
• QuestDB documentation: Symbol
• QuestDB documentation: Write-Ahead Log
• QuestDB documentation: Deduplication
• QuestDB documentation: TTL
• QuestDB documentation: SAMPLE BY
• QuestDB documentation: LATEST ON
• QuestDB documentation: ASOF JOIN
• QuestDB documentation: InfluxDB Line Protocol overview
• QuestDB documentation: PostgreSQL Wire Protocol
• QuestDB documentation: Connect to QuestDB
• QuestDB Enterprise
• questdb repository on GitHub (README)
• questdb repository: LICENSE.txt
• QuestDB release 10.1.0 on GitHub
• InfluxDB 3 Core documentation
• InfluxDB 3 Core: get started and data model
• InfluxDB 3 Core: line protocol reference
• InfluxDB 3 Core: schema design best practices
• InfluxDB 3 Core: create a database (retention)
• InfluxDB 3 Core: data retention internals
• InfluxDB 3 Core: aggregate and select with SQL
• InfluxDB 3 Core: manage tokens
• InfluxDB GitHub repository
• InfluxDB releases on GitHub
• InfluxData pricing
• InfluxData: the future of Flux
• InfluxDB 3 Core: SQL JOIN clause
• InfluxDB 3 Core: fill gaps in data
• InfluxDB 3 Core: miscellaneous SQL functions (interpolate, locf)
• InfluxDB 3 Enterprise documentation
• InfluxDB 3 Enterprise: manage tokens
• Apache License, Version 2.0 (apache.org)
• InfluxDB repository: LICENSE-MIT
• InfluxDB repository: LICENSE-APACHE
• InfluxDB 3 Enterprise: manage your license

Checked October 2026.

How we research comparisons: our editorial method.