Time-series databases
Storage engines built for timestamped streams — millions of vitals per hour, compressed, with time-window queries that stay fast.
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.
Check your recall
0 of 2 recalledActive recall beats re-reading — try to answer, then reveal.
Why not store high-rate vitals in a normal relational table?
What does a TSDB do that a general database doesn't?