Time-Series Storage for Sensor Data
Plexus stores telemetry in ClickHouse. This page explains how that choice compares to three other time-series stores (TimescaleDB, InfluxDB, QuestDB) against the workload a hardware fleet actually generates.
The workload
Sensor telemetry is narrow and relentless: many devices, each emitting the same few metrics on a fixed cadence. The shape is (timestamp, source_id, metric, value) — small rows, high row counts, arriving in batches, almost never updated after write.
The queries
The read side is just as consistent. Five patterns cover most of what a fleet dashboard asks:
| Key | Shape |
|---|---|
Q1_window | one device's last 5 minutes |
Q2_distinct_metrics | distinct metric names for one device |
Q3_fleet_avg | mean across all devices, last 1 minute |
Q4_count_range | count of points in last 10 minutes |
Q5_last_n | last 10 readings for one device |
How they compare
- ClickHouse — columnar storage and aggressive compression fit the append-only, batch-heavy shape directly; fleet-wide aggregates (
Q3,Q4) scan compressed columns instead of rows, and long retention stays cheap. This is what Plexus runs. - TimescaleDB — the draw is Postgres: joins between telemetry and relational data, familiar tooling, one database. The trade is row-oriented storage — larger on disk and slower on wide fleet scans.
- InfluxDB — a purpose-built TSDB that handles this shape well; the trade is a separate query language and ecosystem rather than SQL.
- QuestDB — fast single-stream ingest, but concurrent batch writes are a known failure mode: writer-pool contention surfaces as
table busyerrors and ILP broken pipes. Multi-device fleets need careful write-path design.