How is MQTT Used at the Edge? Deploying Lightweight Messaging at Scale
As data volumes continue to grow at the device edge, sending all data to the cloud is no longer feasible. Increasingly large amounts of data are generated at edge locations, such as energy consumption in retail stores, manufacturing process telemetry, and inference results from on-site computer vision systems. This growth is steady and unavoidable. Transmitting all of this data to a central cloud is impractical, both from a bandwidth and a cost perspective.
Instead, data must be processed and refined close to where it is generated. Only a subset of the data, or the result of local processing, should be forwarded to centralized systems. In these architectures, MQTT is often a core building block.
What is MQTT?
MQTT is a lightweight publish/subscribe messaging protocol that enables producers and consumers to exchange data via named topics. An MQTT broker acts as an intermediary, decoupling data producers from subscribers.
While MQTT is deliberately simple, its topic-based routing model provides significant flexibility. This makes it well suited for developers building distributed, data-intensive edge applications.
The Hidden Complexity of Running MQTT at the Edge
Although MQTT brokers are lightweight, running them reliably at scale introduces challenges, particularly when combined with traditional container orchestration platforms.
A standard Kubernetes control plane introduces significant CPU and memory overhead. In many cases, this overhead exceeds the capabilities of ARM-based industrial gateways commonly used at the edge. These platforms were not designed with constrained hardware in mind.
Kubernetes also assumes stable, continuous connectivity. Components rely on regular heartbeats and frequent reconciliation with the control plane. In edge environments, where connectivity is often intermittent, this becomes a systemic failure point rather than a resilience mechanism.
Operational technology (OT) teams typically prioritize stability and predictability over rapid change. The operational complexity, upgrade cadence, and failure modes of a cloud-native Kubernetes stack often conflict with these priorities.
As a result, the orchestration layer itself can become the largest risk to system stability, rather than the applications it is meant to manage.
Keep reading: Avassa and Kubernetes at the edge – a comparison
MQTT Orchestration and Scale at the Edge
The MQTT brokers used for data collection are often deployed on low-specification edge gateways with limited memory and storage. At the same time, the number of edge sites is typically high, meaning that even small increases in per-node resource requirements quickly translate into significant cost.
For this reason, the orchestration platform must have minimal runtime overhead.
Just as importantly, it must minimize operational overhead. Even modest per-site maintenance costs – whether financial or time-based – do not scale when multiplied across hundreds or thousands of edge locations.
Teams responsible for operating edge infrastructure need tooling that is built for scale: centralized observability, robust lifecycle management, and remote operations. It is not feasible for operators to manually manage individual edge sites. Instead, the orchestration platform must provide a single, coherent view of the entire distributed system—and the ability to act on issues centrally.
Challenges of Secure Data Collection at the Edge
Data collected at the edge is often highly business-sensitive. As a result, strong security controls are not optional, they are foundational. While containerization simplifies deployment, securing containerized MQTT brokers introduces strict requirements on the orchestration platform.
Each broker should expose encrypted endpoints, typically using TLS certificates. In addition, OT teams should premier brokers that authenticate clients using credentials or certificates, enforcing fine-grained access control.
Securely provisioning certificates and credentials, and rotating them regularly, is a critical responsibility of the orchestration platform. In edge environments, this is particularly challenging. Certificate renewal may need to succeed even when an edge site is temporarily disconnected from the cloud. By 2029, best practices may require certificate rotation as frequently as every 47 days.
Without native support for automated certificate and credential management, teams often fall back to insecure patterns: long-lived certificates with 10+ year validity or hard-coded credentials. At scale, frequent manual rotation is simply not realistic.
Why Industrial Edge Computing Demands an “Edge-Native” Approach
The edge is different from the cloud. Industrial edge systems must be designed with an offline-first mindset. Edge workloads should continue to operate and make local decisions, even when connectivity to the cloud is degraded or entirely unavailable.
This is not uncommon; it is an expected operating condition.
MQTT’s publish/subscribe model fits well in these environments. Devices publish sensor data to nearby brokers, decoupling data producers from downstream consumers. Brokers can buffer, cache, filter, or aggregate messages locally, reducing bandwidth requirements and improving resilience.
Network constraints are common in industrial environments. Bandwidth may be limited, and outbound connectivity is often tightly restricted. As a result, data collection systems must tolerate outages and operate autonomously for extended periods.
Keep reading: MQTT with Intermittent Networks Connections
Local processing is frequently used to reduce data volume before transmission. Tools such as Node-RED are commonly deployed alongside MQTT brokers to filter, enrich, and transform raw data streams. All of these edge applications must themselves be lifecycle-managed, further increasing the scale and complexity that the orchestration platform must handle.
Deploying MQTT at Scale
As MQTT adoption grows, deployments often evolve from single brokers to broker clusters, bridges, or hierarchical topologies. Supporting these architectures with low operational overhead is a key requirement for any edge platform.
In manufacturing environments, network segmentation based on standards such as ISA-95 and the Purdue Reference Model is increasingly common. Data destined for the cloud must traverse multiple network layers, often with strict access controls between segments.
In practice, this frequently results in at least one MQTT broker per network segment. Brokers in lower levels may only be permitted to connect upward to a single adjacent layer. Rather than managing one broker near the equipment, teams may need to lifecycle-manage several brokers per site.
The Future of MQTT and Edge Computing
As edge data volumes continue to grow, following the massive increase in Edge AI, the number of deployed MQTT brokers will increase accordingly. MQTT is no longer limited to simple sensor telemetry. Increasingly, AI and machine learning workloads at the edge use MQTT to transport inference results.
MQTT’s simplicity and flexibility make it well suited to these evolving use cases. As edge computing matures, MQTT is likely to remain a foundational protocol for moving data between devices, applications, and systems.
Conclusion
MQTT is a great choice for edge environments. The brokers are typically lightweight and fairly straightforward to configure. Most brokers come with built-in functionality to send certain topics “up the stack,” i.e., towards the cloud. Many sensors and manufacturing equipment come with MQTT support, integration into existing businesses does therefore not have to be complicated.
Given the above, we will see continued and increasing interest for MQTT at the Edge. AI and machine learning deployments will produce even more data, that data will certainly end up on an MQTT topic at your Edge.