140 billion data points a day, zero lost: why MQTT is the energy data backbone

A leading US energy supplier moves 140 billion data points a day from 13 million sensors across more than 400 sites, and during network outages at the edge it loses none of them. When connectivity drops at a remote location, the data buffers locally; when the link comes back, it republishes in chronological order, late but complete. For a utility making power-generation decisions on that telemetry, "late but complete and correctly ordered" is the difference between a usable signal and a dangerous one.

That capability, reliable, event-driven delivery across distributed and unreliable networks, is not something you get from the architecture most energy companies still run. I’ll also be specific about where MQTT is not the answer, because that boundary is where credibility lives.

In the second post in the series, I discussed designing a Namespace for energy assets. In this third post, I share my argument that polling, scheduled batch extraction, and point-to-point integration cannot support real-time energy operations, and that MQTT is the event-driven backbone that can. The protocol matters, but the platform around it is what makes it work at industrial scale. The previous post covered how to design the namespace; this one is about the transport layer that fills it with live data. If a namespace is the structure, MQTT is how the events reach it.

Energy is distributed by nature, and your architecture has to respect that

Energy is not a centralized environment, and never was. A renewables operator has solar in one region, wind offshore, BESS near interconnects, hydro in remote valleys. A utility runs substations, feeders, meters, and reclosers across thousands of locations. An oil and gas company spans offshore platforms, remote well pads, compressor stations, pipeline segments, and refineries.

Upstream oil and gas is the sharpest example: assets sit on offshore rigs, in desert basins, on well pads where bandwidth is expensive and connectivity is intermittent, and where a delayed reading still matters. The same constraint shows up across the sector: offshore wind on microwave or satellite links, grid-edge devices behind strict security boundaries, pipelines stretching hundreds of kilometers. An architecture that assumes a fat, reliable pipe to the cloud is an architecture designed for a data center, not a wind farm.

Why polling and batch quietly tax energy operations

Polling, historians, and scheduled batch movement made sense when the job was reporting. They make less sense when the job is real-time awareness, predictive maintenance, dispatch, emissions visibility, and AI-ready data.

Each pattern adds a tax. Polling adds delay between the event and your knowledge of it. Batch pipelines add latency by design. Point-to-point integrations add fragility, every connection is a thing that can break independently. Cloud-only processing adds dependency on a network link that, as we just established, you cannot count on. Custom site scripts add a maintenance liability that compounds with every site.

The thing to internalize is that a turbine fault, a methane spike, a breaker operation, or a curtailment signal is not data. It is an operational event with a shelf life. The architecture's job is to move that event while it still changes a decision. Batch architecture is structurally incapable of that, no matter how fast the batches run.

How MQTT changes real-time energy data movement

MQTT is event-driven, lightweight, and built on publish-subscribe. Instead of systems repeatedly asking "anything new?", producers publish when something changes and consumers subscribe to the topics they care about. For energy that maps almost too neatly: a turbine publishes active power, wind speed, fault state, curtailment status, vibration; a BESS rack publishes state of charge, state of health, cell temperature; a leak sensor publishes methane concentration, pressure drop, severity. No consumer needs a direct connection to any asset. They subscribe to the relevant slice of the namespace.

This is exactly why Stellar Renewable Power chose MQTT as the backbone protocol for their solar platform (lightweight, publish-subscribe, and suited to high-latency or unreliable links), which is precisely the network profile of remote solar sites. They paired OPC UA at the edge with MQTT transport into the cloud, then Kafka and Databricks behind it. Note the division of labor there, because it's instructive: OPC UA for local device collection, MQTT for the unreliable long-haul. Different protocols for different network conditions, not one protocol forced to do everything.

The MQTT protocol is not the platform

Here's a distinction the marketing usually blurs and that engineers will hold you to: MQTT is a protocol. Running it in production at the scale of a utility is a platform problem.

A leading US energy provider did not succeed because they adopted MQTT. They succeeded because the platform underneath it gave them horizontally scalable clustering, persistent sessions that survive collector disconnects without losing data, message queuing with configurable retention for gap-free delivery, and the buffering-and-replay behavior I described at the top. Those are not properties of the MQTT spec. They are properties of an enterprise broker built to honor the spec's guarantees at 140 billion messages a day. The typical pattern looks like this: an edge layer connects OT assets and protocols close to the source, a clustered broker provides the scalable backbone, a governance layer enforces schema and policy, and a data-intelligence layer adds modeling, validation, and enrichment.

The reason this distinction matters practically: a proof of concept on an open-source broker will work beautifully and tell you almost nothing about whether the architecture survives a site outage, a collector failover, or a tenfold scale-up. The hard problems are all in the platform, not the protocol.

From MQTT topics to a namespace

MQTT gives you transport. Left alone, MQTT topics become their own kind of sprawl, every site publishing in its own way, every OEM with its own naming logic, every project inventing another convention. That's not a foundation; it's the old mess at higher speed.

The Unified Namespace is the structure that prevents it. MQTT moves the data; the namespace makes it understandable; the governance and intelligence layer makes it trustworthy and reusable. That's the full stack, and each layer does a job the others can't. I treat namespace design and governance in their own posts, because each is where most of the real work, and most of the failure, actually happens.

Where MQTT is not the answer

To be straight about the boundary: MQTT is a transport for operational events. It is not a database, and it is not a query engine. If your problem is "I need to run analytical queries over three years of history," MQTT is upstream of that problem, not a substitute for the warehouse that solves it. If your problem is large file transfer (high-resolution imagery, vibration waveforms, video), MQTT is the wrong tool; you publish a reference over MQTT and move the payload another way. And on a single site with reliable wired connectivity and no real-time decision pressure, the operational case for ripping out a working historian is weak. MQTT earns its place where data is distributed, networks are imperfect, and events have a shelf life. That covers most energy operations. It does not cover every workload inside one.

How to audit your energy data architecture for real-time readiness

Audit your current data movement against one question: how long is it between an operational event happening at the asset and a decision-maker being able to act on it? If the honest answer is "minutes to hours, because we poll and batch," you've found the constraint that no dashboard upgrade will fix. The fix is architectural: event-driven transport over a platform engineered for your network reality. The numbers for a US energy provider (zero loss, sub-second latency, 99.9% uptime across 400+ sites) are proof that it holds at the largest scale in the sector.

A word of warning before you start connecting sites, though. Moving data reliably is necessary but not sufficient. The moment you point to a second, differently-configured site at the namespace, you discover that transport was the easy part, and governance was the part you skipped. That's where the next post goes.

To learn how HiveMQ helps energy companies connect remote, distributed assets, explore HiveMQ’s solutions for energy.