Case study
Reports from a 146 GB production database
An internal operations platform that queries the live time-series database directly, where every report is weighed against the load it adds to a system that cannot slow down.
Hospital staff across the country use our platform for reporting and for managing their organizations and groups. The reports they need are built from device telemetry, and that telemetry lives in a 146 GB production TimescaleDB taking in tens of millions of events.
The same database is the one keeping the fleet running. So every report is a negotiation: the query that gives the most accurate answer is often the one that costs the production system the most, and there is no separate warehouse to hide in.
What it is
An internal operations platform built on FastAPI, React and PostgreSQL. It covers reporting, device maintenance and calibration analysis, and it queries the production time-series database directly.
The trade I kept making
Accuracy against load. A report computed over the full raw event history is the most correct thing you can produce and also the most expensive, and the expensive version competes with ingest on a system under active performance monitoring. The useful question is never "what is the best answer" — it is "what is the cheapest query that is still true enough for the decision someone is about to make."
Most of the time the honest answer is that the read cost, not the write throughput, is what hurts. Writes are predictable. It is the reports, which arrive whenever somebody opens a page, that are not.
Where it ended up
Some of this tooling has since been ported directly into the company's production web application as core platform functionality, rather than staying internal.