Abstract

Every energy telemetry project starts the same way. One site, a few thousand channels, a database that answers in milliseconds. Then the pilot becomes a portfolio, and the architecture that worked for one battery site or one charging depot stops working entirely.

The reason is usually not a bad query. It is that nobody drew the boundary. Every database has a range of conditions inside which it performs to spec, and outside which it fails. That boundary is the performance envelope, and it is defined by three things: how much storage you can afford, how fast you can ingest, and how slow your queries are allowed to get.

Battery storage makes the math unforgiving. Cell-level voltage, temperature, and state of charge across a utility-scale site produces tens of thousands of channels per site, and warranty and degradation analysis means you cannot downsample the history away. The data you throw out at month six is the data the claim depends on at year four.

This session walks through how to calculate that envelope for a real fleet-monitoring workload before you commit to an architecture. We do the math on a 25,000 channel deployment at 1 Hz, look at what five years of full-resolution retention actually costs on cloud SSD, and show where the ingest wall sits. Then we look at what happens to that envelope when you add TimescaleDB to Postgres rather than replacing it.

What you'll learn

• How to calculate total data volume and five-year storage cost for a given channel count, sample rate, and retention requirement

• Why compliance and warranty retention windows break the assumptions behind most downsampling strategies

• Why the maximum ingest rate degrades as a Postgres table grows, and how to spot the backlog before it becomes unrecoverable

• Where vertical scaling, sharding, and a purpose-built time-series database each stop being the right answer

Can’t make it live? Register anyway and we’ll send you the recording.