Two billion rows of operating history with fast local queries and a small CPU footprint across three production energy sites
At DJIN EMS, we record 35 million rows of energy data every day with TDengine TSDB. By September 2026, our three operating sites had accumulated more than two billion rows in under seven months. TDengine uses about 2% of one CPU core per appliance, keeping compute available for our 50 Hz control loop and Genie, our local AI assistant.
Nick Hughes
CEO and Co-founder, DJIN EMS
TDengine gives us a complete, high-resolution record of every site on the same appliance that runs real-time control. Two billion rows, 50 Hz control data and 60 fps synchrophasors, and it uses about two percent of one CPU core. That headroom is what lets us put control, history and local AI in one box.
| Production result | What TDengine delivers |
|---|---|
| 870 million rows in 21 GiB | Our busiest site’s entire operating history fits on its local appliance. |
| 11× compression at 50 Hz | Detailed control records take approximately 91% less space than the uncompressed estimate. |
| About 20 ms for a daily trend | A 24-hour query aggregates approximately 860,000 rows into one-minute windows.¹ |
| Under 1 second for a weekly rollup | A query rolls up as many as 36 million synchrophasor rows into one-minute windows.¹ |
Our energy appliance brings control history and AI together
We build GenieOS for battery energy storage and the grid edge. Our turnkey appliance monitors and controls batteries, power conversion systems, generators, meters and protection equipment from multiple vendors. Our growing driver library connects new equipment, while Genie gives operators a local AI assistant that works without a cloud AI service.
We need to preserve every device reading, control cycle and grid disturbance beside the software operating the site. TDengine makes that high-resolution record practical on the same rugged industrial PC, even where internet connectivity is unreliable.
Why we selected TDengine over the alternatives
When we designed GenieOS, I selected TDengine as our primary time-series database for performance, compression and the fit with industrial equipment data. My July 2025 assessment compared TDengine, VictoriaMetrics and PostgreSQL with TimescaleDB, considered ClickHouse, and drew on published comparisons with InfluxDB.
I wanted a dedicated time-series engine, SQL, a table per device, supertables for equipment classes, and simple local deployment. That combination now supports our production platform recording 35 million rows a day while using about 2% of one CPU core per appliance.
| Alternative considered | Why TDengine was the stronger fit for us |
|---|---|
| VictoriaMetrics | We needed a database organized around sites, block controllers and physical equipment. In my assessment, TDengine’s supertables, subtables and tags mapped more directly to that hierarchy than a Prometheus-oriented metrics model. Time-series SQL matched our historian API and engineering analysis. In production, TDengine metadata also enabled 200–300× faster device discovery within our application. |
| TimescaleDB PostgreSQL extension from Tiger Data | We chose a purpose-built time-series engine for continuous telemetry and high-rate control records. My assessment favored TDengine’s expected ingestion performance, storage efficiency and resource use. I recommended PostgreSQL for user, configuration and application-state data alongside TDengine for industrial telemetry, giving each workload a defined purpose. |
| InfluxDB | I reviewed published ingestion, query and disk-use results as part of the performance assessment. Device-oriented storage and SQL added a close architectural fit. I favored TDengine’s combination of compression, read and write performance, and a device-oriented schema for the local operating history we needed in GenieOS. |
| ClickHouse | I considered ClickHouse for analytics and selected TDengine for our appliance’s primary operating history. TDengine combined per-device records, equipment-class aggregation, time-series SQL and database-enforced retention in the model we needed for continuous collection and local investigation. |
| PostgreSQL for operational data | My design recommendation paired PostgreSQL for relational operational data with TDengine for telemetry, high-speed control records and historical queries. This focused TDengine on the workload where its time-series design, compression and device hierarchy offered the greatest value to our platform. |
Our choice is working in operating projects
Our production results give that decision concrete weight. We store 870 million rows in 21 GiB at our busiest site, retrieve a daily trend in about 20 ms, and roll up a week of high-rate synchrophasor data in under a second. The database leaves our appliances’ compute available for the control and local AI that distinguish GenieOS.¹
How TDengine runs inside our appliances
We use a supertable for each data class and a subtable for each physical device. Tags identify the site, block, vendor and model. Live metadata lets our interface discover new measurements as our equipment drivers expand.
Each of our appliances runs one TDengine TSDB Docker container on a dedicated NVMe historian drive. Asynchronous, batched writers flush multi-table inserts within one second, keeping database writes off our 50 Hz real-time control path.
We use four databases to enforce separate retention windows, including 30 days for 50 Hz control records and 21 days for 60 fps IEEE C37.118 synchrophasors. Microsecond timestamps preserve event order. Operators, Genie and our engineers retrieve history through the same local API.
Our production results across three energy sites
We measured the following results on our production appliances on 16 September 2026.
| Measure | Our production result |
|---|---|
| Deployment | 3 operating energy sites, with the first live since February 2026 |
| Operating history | More than 2 billion rows, all written in under seven months |
| Daily collection | 35 million rows per day, including 50 Hz control and 60 fps synchrophasors |
| Overall compression | Approximately 7×, equivalent to about 86% less storage |
| 50 Hz control compression | Approximately 11×, equivalent to about 91% less storage |
| Busiest site | 870 million rows in 21 GiB for the entire historian |
| Control record size | Approximately 14 bytes per 23-field row on disk |
| 24-hour trend | Approximately 20 ms over about 860,000 rows, in one-minute windows¹ |
| One-week grid-data rollup | Under 1 second over up to 36 million rows, in one-minute windows¹ |
| Database CPU footprint | Approximately 2% of one CPU core on each appliance |
| Device discovery | 200–300× faster after we switched discovery to ins_tags |
| On-disk migration | Approximately 5 seconds per site during a major-version upgrade |
| Fleet-wide upgrade | Completed in 2 days across the deployment |
¹ We recorded these measurements on 16 September 2026. Query times use a warm cache on the production appliance. Compression ratios are relative to TDengine’s uncompressed-size estimate in information_schema.ins_disk_usage; percentage storage reductions are calculated from those ratios.
What we like about TDengine
A data model that matches our drivers
Supertables, subtables and tags map one-to-one onto device classes, devices and site hierarchy. Metadata queries (ins_tags, DESCRIBE) power a self-describing historian: switching device discovery to ins_tags made it 200–300× faster.
Compression that removes the storage question
Our busiest site’s entire historian (870 million rows) takes 21 GiB. The 50 Hz control-loop stream compresses 11×, so high-rate diagnostics cost almost nothing to keep.
Time-series SQL
INTERVAL windows with FILL, tag filters and PARTITION BY turn trends, envelopes and multi-device correlations into single statements. Our historian API and AI tooling build them from safe, allow-listed templates.
Retention per stream
Database-level KEEP gives each stream its own window. High-rate streams roll off automatically, enforced by the engine rather than by cleanup jobs.
A small, predictable footprint
About 2% of one CPU core leaves the appliance’s compute for real-time control and local AI.
Easy to deploy and run
One container per appliance and no cluster to manage. Our fleet-wide major-version upgrade finished in two days, with a ~5-second on-disk migration per site.
A production foundation for GenieOS
With TDengine, we deliver an energy appliance that keeps detailed history available at the site, answers large historical queries quickly, and leaves compute for control and local AI. Three live sites, two billion rows and 35 million new rows each day show that our architecture is already working in real energy projects.
Sources: DJIN EMS, Two billion rows at the grid edge, September 2026; Database Technology Analysis, July 2025. Our production figures reflect measurements on 16 September 2026. Customer site identities are withheld.
