A modern PV or wind site emits tags relentlessly: inverter power and DC string currents, nacelle wind speed, transformer temperatures, meter registers, dozens of OPC UA or Modbus points sampled every second or faster. Dropped into an ordinary relational table, that stream becomes a slow, bloated archive nobody can query in production. The data is time-series, and it wants storage built for that shape.
Telemetry is append-only, ordered by time, and almost always read by time window — store it that way.
What a time-series engine actually buys you
A TSDB exploits the one property generic tables ignore: rows arrive in time order, change little between samples, and are queried by window rather than by primary key. Columnar compression on slowly varying signals — a string current that barely moves second to second — routinely shrinks raw telemetry by 10x or more, the difference between keeping a year of one-second data online and silently downsampling it away. Time partitioning (hypertable-style chunking) keeps writes cheap and lets old ranges age out without table-wide locks.
The query layer matters as much as the storage. Time-bucketing turns ragged sub-second samples into clean 1-minute, 15-minute or hourly intervals on read, aligned to the boundaries your market settles on. Continuous aggregates precompute those rollups and refresh incrementally, so a year-over-year availability chart never rescans billions of raw rows. Pair that with tiered retention — raw data for a few weeks, then minute and hourly aggregates kept for years — and the layer stays honest at full resolution and fast at fleet scale.
Where relational still wins
A TSDB is the wrong home for the things that do not change every second. Plant and asset hierarchies, inverter and meter nameplate data, tag-to-signal mappings, calibration records, commissioning dates, ownership and contract metadata — these are relational by nature. They need foreign keys, constraints and the occasional update, and they are small. A normalised relational schema gives them referential integrity and clean joins that a time-series store is not built to enforce.
In practice the two live side by side: the TSDB holds the measurements, the relational schema holds the model of the plant, and a stable tag identity links them. Resolve assets and configuration relationally, then aggregate the readings in the TSDB. That separation keeps both halves fast and lets the metadata evolve without ever rewriting the telemetry history.
Getting this split right is unglamorous and decisive: a TSDB for the firehose of measurements, a relational schema for the assets and configuration that give those measurements meaning. Done well, it is what forecasting, anomaly detection and market settlement all build on. It is exactly the kind of data layer we build and keep running.