Time-series databases

In one line

A time-series database (TSDB) optimises for one shape of data — (timestamp, source, value) at high rates — with time-based partitioning, heavy compression, and windowed aggregation as first-class operations.

The problem it solves

A normal relational table chokes on telemetry: a single 1 Hz vital-sign feed is 86,400 rows per patient per day, and you mostly query time windows ("average HR per minute over the last 6 hours"), not individual rows. General tables get huge and slow; indexes bloat. A TSDB is purpose-built for exactly this access pattern.

How it works

• Append-only, time-ordered chunks — writes go to the newest chunk, which is cheap.
• Heavy compression — old chunks compress 10–20× (adjacent timestamps and similar values compress beautifully).
• Time-native queries — per-minute averages, downsampling for charts, and continuous aggregates maintained as data arrives.
• Retention policies — old data ages out automatically by rule.

Options range from Postgres-native (TimescaleDB — your relational data and telemetry in one database) to dedicated engines (InfluxDB, ClickHouse for analytics-heavy loads).

Where it shows up in digital health

• Vital-sign histories from monitors and RPM (the 86,400-rows/day problem).
• ICU waveform archives and high-rate device data.
• Device-fleet metrics and the storage behind every "trend" chart.

The platform rule of thumb already in the docs: lab telemetry stays out of the main Postgres tables; a TSDB joins when a real stream does. It pairs naturally with Kafka (ingest) and edge computing (downsample before storing).

Common pitfalls

• Using a normal table for high-rate streams — it works until it suddenly doesn't (and migration under load is painful).
• No downsampling/retention plan — raw high-rate data grows without bound; decide what to keep at full resolution.
• Forgetting PHI governance — vitals tied to a patient are still PHI, wherever they're stored.

Key takeaways

• A TSDB is tuned for (timestamp, source, value) at high rates — fast appends, time-window queries.
• Compression (10–20×), continuous aggregates, and retention are first-class.
• TimescaleDB keeps it in Postgres; InfluxDB/ClickHouse are dedicated alternatives.
• Essential once real device streams arrive — keep telemetry out of your main tables.