Time-Series Databases for Edge Telemetry 2026 — Storage Sizing, SSD Endurance & Engine Choices

Machine vibration, energy meters, PLC registers, temperature sensors and fleet telemetry generate the quiet majority of edge data — and nearly all of it is time-series. Before any anomaly model or dashboard exists, that data has to land in a time-series database (TSDB) on the edge node itself, because streaming raw telemetry to the cloud at industrial rates is expensive and often impossible on constrained uplinks. Most hardware buyers size the box for the AI model and leave the database as an afterthought — which is how a $3,000 inference node ends up with a worn-out consumer SSD and six months of missing history. This guide covers the 2026 engine choices, the points-per-second sizing math, and the storage endurance decisions that keep telemetry history intact.

Which TSDB engine runs where

Treat every ingest number as an order-of-magnitude guide, not a spec: real throughput depends on tag cardinality, batch sizes and disk, and ARM nodes typically land 30–50% below equivalent x86 on write-heavy loads. The 2026 pattern that works best at the edge: Prometheus for node/infrastructure metrics (short retention), one TSDB for process data (the historian role), and object storage or Parquet export for the cold archive. On constrained ARM gateways, TDengine and InfluxDB have the most mature aarch64 packaging; QuestDB is the pick when query latency on high-rate streams matters more than ecosystem.

Sizing math: from sensors to terabytes

Telemetry sizing is arithmetic, and the assumptions matter more than the engine. A representative line-protocol point (timestamp + tag + field + overhead) runs ~100 bytes before compression. Columnar engines cut stored bytes 3–10×, but plan uncompressed for capacity and compressed for endurance. Take a mid industrial site: 500 sensors at 1 Hz is 500 points/s ≈ 50 KB/s ≈ 4.3 GB/day ≈ 130 GB/month raw — trivial for any modern SSD. The math changes when rates climb: high-frequency vibration envelopes or DAQ bursts at 50,000 points/s write ~400 GB/day, and a year of that is 150 TB — a tiering problem, not a single-disk problem. The burst case, not the steady case, is what forces the hardware spec.

Retention policy is the biggest lever: keep 7 days hot on NVMe for dashboards, 90 days warm on cheaper SATA SSD for model training, and push everything older to MinIO-style object storage or Parquet archives — the deep-history queries that motivated "keep everything forever" almost never hit the hot tier. Downsample as well (1 Hz → 1/min aggregates after 30 days) before buying more disk.

Endurance math: what 24/7 writes do to flash

Steady telemetry is a gentle write load — 4.3 GB/day on a 2 TB drive is ~0.05 drive-writes-per-day, far inside consumer endurance. But DB engines amplify writes: LSM-tree compaction and WAL/commit-log traffic can multiply raw data 2–5×, and an under-spec'd drive in a DAQ-burst deployment dies fast. The useful check is DWPD: a drive rated 0.5 DWPD over 5 years on 2 TB handles ~1,800 TBW, and a 150 TB/year burst workload consumes that in ~4 years once compaction and RAID-rebuild amplification are counted — which is exactly why industrial pSLC or high-endurance TLC drives with power-loss protection belong in the historian role, and why a mirrored pair beats a single large drive. On single-node sites, add a small UPS or a PLP-equipped drive: a power cut mid-compaction corrupts more telemetry than any hardware failure.

Platform selection

The recurring mistake is co-locating the historian and the AI on one small SSD "because the model is small." The AI model is compute; telemetry history is a durability contract. Give the database its own mirrored storage, match the drive endurance to the burst case not the average, and size RAM for the engine's working set — TSDBs are happier with 32 GB and a fast disk than 128 GB and a slow one.