Battery storage systems and EMS platforms are generating data at unprecedented speed and scale. With thousands of devices streaming telemetry — voltage, current, SoC, temperature, alarms — every second, many operators are discovering the hard way that their existing data infrastructure can’t keep up.
Dropped data, slow dashboards, spiraling cloud costs, and fragile edge–cloud architectures are common symptoms of systems not built for high-frequency, time-series workloads. But TDengine was designed for this exact challenge. To validate its capabilities in a realistic scenario, we ran a full-scale test.
Key Results:
- Ingestion throughput: 872,615 points per second
- Compression ratio: 31.49:1
- Edge–cloud synchronization: Zero data loss
These results validate TDengine’s ability to ingest, store, replicate, and query massive volumes of telemetry data — reliably, efficiently, and with minimal infrastructure.
Test Setup
Environment
All tests were run in Amazon Web Services (AWS) on machines described in the following table.
Node | Instance type | CPUs | Memory |
---|---|---|---|
ems-center-1 | t3.xlarge | 4 | 16 GB |
ems-center-2 | t3.xlarge | 4 | 16 GB |
ems-center-3 | t3.xlarge | 4 | 16 GB |
ems-client-node | t3.xlarge | 4 | 16 GB |
ems-edge-1 | c6i.8xlarge | 20 | 64 GB |
ems-edge-2 | c6i.8xlarge | 20 | 64 GB |
ems-flashmq-1 | t3.xlarge | 4 | 16 GB |
ems-flashmq-2 | t3.xlarge | 4 | 16 GB |
ems-mqtt-1 | m6i.4xlarge | 16 | 64 GB |
ems-mqtt-2 | m6i.4xlarge | 16 | 64 GB |

Methodology
TDengine has created a public repository on GitHub that simulates a typical BESS deployment using containerized edge and cloud nodes. This environment is fully open source and can be forked by anyone wishing to perform similar tests.
For this test, we used a GitHub Actions pipeline on the environment described above. The pipeline created 10 MQTT publishers that send data to the two TDengine edge nodes. The edge nodes then synchronize this data to the central nodes. We used Grafana to monitor the central database and determine the ingestion and compression rates for the simulated data.
Results Breakdown
Metric | Value |
---|---|
Ingestion rate | 872615.91 points per second |
Edge CPU usage | 67.6% of 20 cores |
Edge memory footprint | 1.23 GiB |
Central CPU usage | 20.7% of 4 cores |
Central memory footprint | 577 MiB |
Takeaway: TDengine handled massive ingestion rates smoothly — no Kafka, load balancers, or buffering layers required.
Why It Works
TDengine’s architecture is purpose-built for IoT and industrial telemetry:
- “One table per device” model enables extreme compression and parallelism.
- Columnar storage engine accelerates aggregations and filters.
- Built-in edge–cloud sync ensures data continuity without third-party tools.
Unlike general-purpose databases, you don’t need a patchwork of tools to make TDengine work. It’s all built-in.
Final Takeaways
If you’re running an EMS, BESS platform, or large-scale battery analytics solution, and struggling with:
- Real-time ingestion at scale
- Long-term data retention costs
- Edge-to-cloud consistency
- Sub-second analytics for operations
Then this test proves what TDengine can do for you. Contact us today for a tailored demo or PoC, or join our hands-on workshop on June 18 to try our system for yourself.