How DJIN EMS Captures 35 Million Rows a Day with TDengine at the Grid Edge

Executive Summary

DJIN EMS records 35 million rows of energy data every day with TDengine TSDB. By September 2026, its three operating energy sites had accumulated more than 2 billion rows in under seven months. TDengine uses about 2% of one CPU core per appliance, keeping compute available for the 50 Hz control loop and Genie, the local AI assistant.

Across three production sites, TDengine keeps a complete, high-resolution record of every site on the same appliance that runs real-time control, leaving compute available for the control and local AI that distinguish the GenieOS platform.

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.

Control, History and AI on One Energy Appliance

DJIN EMS builds GenieOS for battery energy storage and the grid edge. The turnkey appliance monitors and controls batteries, power conversion systems, generators, meters and protection equipment from multiple vendors. A growing driver library connects new equipment, while Genie gives operators a local AI assistant that works without a cloud AI service.

The platform preserves 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 DJIN EMS Selected TDengine

When GenieOS was designed, TDengine was selected as the primary time-series database for performance, compression and the fit with industrial equipment data. A July 2025 assessment compared TDengine, VictoriaMetrics and PostgreSQL with TimescaleDB, considered ClickHouse, and drew on published comparisons with InfluxDB.

The requirement was a dedicated time-series engine, SQL, a table per device, supertables for equipment classes, and simple local deployment. That combination now supports the production platform recording 35 million rows a day while using about 2% of one CPU core per appliance.

  • VictoriaMetrics: TDengine’s supertables, subtables and tags mapped more directly to the hierarchy of sites, block controllers and physical equipment than a Prometheus-oriented metrics model, and time-series SQL matched the historian API. In production, TDengine metadata enabled 200–300× faster device discovery.

  • TimescaleDB: a purpose-built time-series engine was favored for continuous telemetry and high-rate control records, with PostgreSQL recommended for user, configuration and application-state data alongside TDengine.

  • InfluxDB: published ingestion, query and disk-use comparisons favored TDengine’s compression, read and write performance, and device-oriented schema.

  • ClickHouse: considered for analytics, while TDengine was selected for the appliance’s primary operating history with per-device records, equipment-class aggregation, time-series SQL and database-enforced retention.

  • PostgreSQL: kept for relational operational data, focusing TDengine on telemetry, high-speed control records and historical queries.

How TDengine Runs Inside the Appliances

Each data class uses a supertable and each physical device a subtable. Tags identify the site, block, vendor and model. Live metadata lets the interface discover new measurements as equipment drivers expand.

Each appliance 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 the 50 Hz real-time control path.

Four databases 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 the engineers retrieve history through the same local API.

Production Results Across Three Energy Sites

The following results were measured on the production appliances on 16 September 2026:

  • 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 switching 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

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. Customer site identities are withheld.

Why TDengine Fits GenieOS

A data model that matches the 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

The 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. The 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. The fleet-wide major-version upgrade finished in 2 days, with a ~5-second on-disk migration per site.

A Production Foundation for GenieOS

With TDengine, DJIN EMS delivers 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 this architecture is already working in real energy projects.

About DJIN EMS

DJIN EMS builds GenieOS, an on-site energy management platform for battery energy storage and the grid edge, combining real-time control, a full-resolution historian and local AI on a single appliance.

For more information, visit https://djinems.com.

Note: This case study is originally published by TDengine. As an official partner, OpenDataTechs provides localized product sales, solution design, deployment and consulting services in EU and UK.IMGTEST-BEFORE

IMGTEST-AFTER

TDenginePI SystemAB

TABLETEST-END

Interested? contact us