TimescaleDB vs InfluxDB vs QuestDB for IIoT Telemetry

Picking a time-series database for factory telemetry is a decision you live with for years, because migrating billions of rows of OEE history is expensive and risky. This page sits under time-series database sync and compares the three engines that come up most often in manufacturing deployments — TimescaleDB, InfluxDB, and QuestDB — on the dimensions that actually bite in production: sustained ingest rate from thousands of concurrent PLC tags, compression ratio on mostly-repetitive sensor data, how cleanly each engine downsamples raw telemetry into shift-level rollups, and what happens to query performance once tag cardinality — driven directly by ISA-95 equipment hierarchy tag naming — climbs past a few hundred thousand active series.

TimescaleDB #Permalink to this section

TimescaleDB is a PostgreSQL extension: telemetry lands in ordinary relational tables that Postgres automatically partitions into time-and-space chunks via a hypertable. The practical consequence is that OEE joins across a telemetry hypertable and a slow-changing equipment_hierarchy dimension table — the kind of query oee-reporting rollups run constantly — are native SQL joins, not a cross-system lookup. Ingest is a normal INSERT/COPY, so the idempotent upsert pattern from time-series database sync applies unmodified.

-- Hypertable partitioned by time, chunked to keep each chunk memory-resident
CREATE TABLE telemetry (
    canonical_id   text        NOT NULL,
    ts             timestamptz NOT NULL,
    value          double precision,
    quality        text        NOT NULL DEFAULT 'GOOD'
);
SELECT create_hypertable('telemetry', by_range('ts', INTERVAL '1 day'));

-- Native columnar compression: order by tag, segment by time
ALTER TABLE telemetry SET (
    timescaledb.compress,
    timescaledb.compress_orderby = 'ts DESC',
    timescaledb.compress_segmentby = 'canonical_id'
);
SELECT add_compression_policy('telemetry', INTERVAL '7 days');

Compression on repetitive sensor data (steady-state analog signals, sparse discrete transitions) commonly reaches 90–95% size reduction once a chunk is compressed, because the segment-by-tag, order-by-time layout lets Postgres delta-encode within a tag’s own value series. TimescaleDB’s cardinality tolerance is moderate: it inherits Postgres index behavior, so a canonical_id column with a B-tree or hash index handles hundreds of thousands of distinct tags comfortably, but it is not purpose-built for the multi-million-series cardinality that a tag-per-batch-ID anti-pattern would create — the same discipline that keeps ISA-95 tag naming cardinality-bounded matters here directly. Operationally, TimescaleDB benefits from the enormous Postgres ecosystem (backup tooling, pg_stat_statements, connection poolers, and every BI tool’s native Postgres driver) at the cost of Postgres’s own write-ahead-log and vacuum overhead under very high insert rates.

InfluxDB #Permalink to this section

InfluxDB is purpose-built as a time-series-native store: every write is a (measurement, tag set, field set, timestamp) point, and tags — not fields — are the indexed, queryable dimensions. This is a genuinely different data model from a relational table, and it is why InfluxDB’s cardinality story is framed differently: cardinality is the product of unique tag-value combinations across all tag keys, and the engine is optimized to shard and index against that product directly rather than relying on a general-purpose B-tree.

-- InfluxDB v3 / IOx uses SQL over an Arrow/Parquet-backed engine
SELECT
    canonical_id,
    date_bin(INTERVAL '1 minute', time, TIMESTAMP '2026-07-15T00:00:00Z') AS bucket,
    avg(value) AS avg_value
FROM telemetry
WHERE canonical_id IN ('LINE_03.CNC_07.SPINDLE_SPEED', 'LINE_03.CNC_07.FEED_RATE')
  AND time >= TIMESTAMP '2026-07-15T06:00:00Z'
  AND time <  TIMESTAMP '2026-07-15T14:00:00Z'
GROUP BY canonical_id, bucket
ORDER BY canonical_id, bucket;

Out-of-the-box compression is strong because InfluxDB’s storage engine (TSM in earlier versions, an Arrow/Parquet-based columnar engine in InfluxDB 3.x) is designed around exactly this workload shape: many series, mostly-monotonic timestamps, high value repetition. Where InfluxDB gives up ground against TimescaleDB is relational depth — joining telemetry against a normalized equipment-hierarchy dimension table is awkward compared to a native SQL join, and complex multi-table OEE reconciliation queries (the kind in reconciling OEE with MES production counts) are more naturally expressed in Postgres-flavored SQL than in a tag/field model built primarily for time-bucketed aggregation.

QuestDB #Permalink to this section

QuestDB is a columnar, append-only engine tuned for the single highest-throughput workload of the three: one writer, sustained high-frequency ingest, with out-of-order commits handled by its own commit-lag buffer rather than a general-purpose transaction log. It exposes a SQL surface (including a native LATEST ON and SAMPLE BY syntax purpose-built for time-series) over tables partitioned by time and, optionally, hashed by a SYMBOL column — QuestDB’s equivalent of an indexed low-cardinality tag type.

CREATE TABLE telemetry (
    canonical_id SYMBOL CAPACITY 500000 CACHE,
    ts           TIMESTAMP,
    value        DOUBLE,
    quality      SYMBOL CAPACITY 8
) TIMESTAMP(ts) PARTITION BY DAY WAL
  DEDUP UPSERT KEYS(canonical_id, ts);

-- SAMPLE BY: QuestDB's dedicated time-bucketing syntax
SELECT canonical_id, ts, avg(value) AS avg_value
FROM telemetry
WHERE ts BETWEEN '2026-07-15T06:00:00.000000Z' AND '2026-07-15T14:00:00.000000Z'
SAMPLE BY 1m
FILL(PREV);

The SYMBOL type is the key cardinality lever: it is dictionary-encoded per partition, giving excellent scan performance up to the configured CAPACITY, but sizing it wrong (too low for the true tag count) causes hash collisions that silently degrade query plans rather than failing loudly — this is the one engine of the three where cardinality planning is a manual, explicit schema decision rather than something the engine absorbs transparently. QuestDB’s DEDUP UPSERT KEYS clause on a WAL table gives the idempotent-write guarantee natively, without the ON CONFLICT upsert pattern TimescaleDB needs. In exchange for its ingest speed, QuestDB’s relational feature set (foreign keys, arbitrary multi-table joins) is thinner than Postgres’s, and its operational tooling ecosystem, while growing, is younger than either competitor’s.

A decision framework #Permalink to this section

None of the three is universally correct; the right choice follows from which constraint is tightest in your deployment. If OEE reporting leans heavily on relational joins against MES/ERP dimension tables and the team already runs Postgres, TimescaleDB minimizes both migration risk and the cognitive cost of a second query language. If the plant’s tag cardinality is large and highly dynamic — many short-lived tags from a rotating fleet of mobile assets or frequently reconfigured cells — InfluxDB’s tag-native model absorbs that shape more gracefully than a relational index. If the binding constraint is raw single-writer ingest throughput from a very high-frequency line (multi-kHz vibration or current waveforms feeding predictive maintenance, not just 1 Hz OEE telemetry), QuestDB’s append-only columnar engine and native SAMPLE BY/DEDUP primitives give the highest ceiling, at the cost of doing cardinality planning by hand.

All three support the continuous-aggregate and downsampling retention pattern that keeps raw-resolution storage bounded — TimescaleDB with native continuous aggregates, InfluxDB with tasks or Flux/SQL-scheduled downsampling, QuestDB with SAMPLE BY materialized into a rollup table on a cron — so the downsampling strategy itself should not be the deciding factor; the deciding factor is which engine’s native data model matches your dominant query shape.

Retention and storage-tiering behavior also differ enough to matter at scale. TimescaleDB pairs compression policies with a drop_chunks retention policy, so old chunks can be compressed for months before eventual deletion, and Timescale’s tiered-storage add-on can move cold chunks to object storage without changing the query surface. InfluxDB applies retention at the bucket level, and InfluxDB 3.x’s Parquet-backed storage is natively friendly to object-storage tiering, since the on-disk format is already columnar and portable. QuestDB relies on partition-level retention (ALTER TABLE ... DROP PARTITION), which is explicit and scriptable but currently requires more operational scaffolding to tier cold partitions off local disk than the other two. None of these differences should override the data-model fit discussed above, but they do change the total cost of keeping years of shift history queryable rather than archived.

Gotchas & anti-patterns #Permalink to this section

• Choosing on synthetic benchmark numbers alone. Vendor benchmarks are usually run on cardinality and write patterns that do not resemble a factory floor’s mix of steady analog streams and bursty discrete events; benchmark with your own tag mix before committing.
• Under-sizing QuestDB SYMBOL CAPACITY. A capacity set below true cardinality causes silent hash collisions that degrade query plans without an obvious error — size it from the actual tag registry, not a guess.
• Treating InfluxDB tags like relational foreign keys. High-cardinality relational lookups (joining to a full equipment-hierarchy dimension table with dozens of attributes) fight the tag/field model; keep that join in the application layer or a relational sidecar.
• Skipping compression policy configuration on TimescaleDB. A hypertable without an explicit compression_policy stores every chunk uncompressed indefinitely — compression is opt-in per hypertable, not automatic.
• Ignoring out-of-order write behavior under each engine. Late-arriving buffered data from a store-and-forward recovery behaves differently in each engine’s commit model; test replay explicitly rather than assuming ordering guarantees carry over from the happy path.

Quick reference #Permalink to this section

Related #Permalink to this section

• Time-Series Database Sync — the parent write-contract this comparison assumes
• Continuous Aggregates and Downsampling Retention Policies — the rollup strategy layered on top of whichever engine is chosen
• ISA-95 Equipment Hierarchy Tag Naming Conventions — the naming discipline that keeps series cardinality bounded in any engine
• Syncing Edge Timestamps with NTP Servers — clock discipline that all three engines assume is already in place