Your IoT sensors speak MQTT — so do your microservices, and the same broker connects them
MQTT rules industrial IoT, AMQP powers RabbitMQ 4.x, and NATS is taking over cloud-native messaging. Here is how these three protocols coexist in 2026 network architectures.
February 2026. Mosquitto 2.1.2 ships with 11,000 GitHub stars and the crown of the most-deployed MQTT broker on the planet. June 2026. EMQX 6.2.1 hits 16,400 stars and claims 100 million concurrent MQTT connections on a 23-node cluster. Sandwiched between them, RabbitMQ 4.x swaps its metadata engine for Khepri, and NATS graduates from CNCF incubation to become the default cloud-native messaging backbone.
Three protocols, one job: moving messages between machines that do not know each other exist. And in 2026, the line between IoT and backend has vanished.
MQTT: a 2-byte header that connects a billion sensors
MQTT (Message Queuing Telemetry Transport) was born in 1999 at IBM to monitor oil pipelines over satellite links. The design brief was brutal: a 2-byte fixed header, a persistent TCP connection, and three quality-of-service levels that let you trade speed for reliability on a per-message basis.
The protocol was standardized by OASIS in 2013. Version 5.0, finalized in March 2019, added shared subscriptions (multiple consumers on one topic), message expiry, and a request-response pattern. These additions lifted MQTT beyond sensors — your microservices can talk MQTT just fine.
The architecture is publish/subscribe through a central broker. A client publishes to a topic (plant/line4/press/temperature), and every subscriber to that topic receives the message. No service discovery, no IP addresses to hardcode.
The three QoS levels frame every architectural decision:
- QoS 0 — fire and forget. No acknowledgment. For telemetry where a dropped reading does not matter.
- QoS 1 — at least once. The sender retransmits until acknowledged. Duplicates are possible. This is the production default.
- QoS 2 — exactly once. A four-step handshake guarantees a single delivery. The overhead is real; it is rarely justified outside financial transactions.
Last Will is the underrated feature that makes MQTT a supervision tool: every client can register a message the broker publishes automatically if the connection drops. A sensor that goes offline triggers an alert instantly, with no polling loop.
Mosquitto vs EMQX: two philosophies, one wire protocol
Mosquitto is written in C, weighs a few hundred kilobytes, and runs on a Raspberry Pi as happily as on an x86 server. Its single-threaded architecture caps it at roughly 160,000 concurrent connections and 120,000 messages per second at QoS 0. For 90 % of IoT deployments, that is more than enough. It is the default choice for engineers who want a lightweight, deterministic, zero-surprise broker.
EMQX is written in Erlang/OTP, runs a masterless distributed architecture, and scales to 4 million connections per node. Its headline feature: MQTT over QUIC, which replaces TCP with Google’s multiplexed UDP protocol. The payoff is zero head-of-line blocking, seamless network handover (WiFi → 5G), and connection setup times cut in half over high-latency links.
Here is how they stack up:
The real-world pattern: Mosquitto at the edge, EMQX in the cloud. They bridge natively over MQTT — a sensor publishes to a local Mosquitto, the bridge relays to a regional EMQX cluster, and the central dashboard subscribes without knowing where the message originated.
AMQP: the protocol that built RabbitMQ
AMQP (Advanced Message Queuing Protocol) is an enterprise messaging protocol standardized by OASIS in 2011. Unlike MQTT, which only understands topics, AMQP introduces a three-tier routing model: exchanges receive messages, bindings define routing rules, and queues hold messages awaiting consumption.
An exchange can route by topic key, by header, as a fanout (all queues), or direct. This flexibility makes AMQP the natural fit for enterprise application integration: an ERP publishes a manufacturing order, a MES consumes it, the billing system gets a fanout copy.
RabbitMQ is the reference AMQP implementation. Version 4.x, released in 2025, replaces the legacy Mnesia metadata store with Khepri, a Raft-inspired consensus engine. Network partitions resolve in seconds instead of minutes, and cluster stability no longer requires a full-time operator.
RabbitMQ also speaks MQTT 5.0 and STOMP through plugins, turning a single instance into a multi-protocol hub that talks MQTT to a sensor and AMQP to a Java backend.
NATS: the newcomer that changes the game
NATS is a cloud-native messaging system created by Derek Collison, the architect behind the TWS electronic trading platform’s messaging layer. The philosophy: a sub-10 MB binary, zero external dependencies, sub-millisecond latency.
Three properties set NATS apart:
- Zero-config clustering. A NATS node auto-discovers its peers. Standing up a three-node cluster is literally one command per node.
- Superclusters. Geographically separate clusters merge into a single global namespace. A message published to
plant.paris.line4is reachable fromplant.singapore.line4with no explicit bridge. - JetStream. The persistence layer added in 2021 brings per-subject retention policies, consumer groups, and exactly-once delivery — the missing piece that kept NATS from competing with Kafka on stateful workloads.
NATS graduated from CNCF incubation in 2024. The 2026 roadmap focuses on Leaf Nodes for edge computing: a NATS node on an industrial gateway accepts local MQTT connections and replicates them into the supercluster with no application changes.
The comparison table
Which protocol for which layer in 2026?
The question is no longer “which one” but “in what order.” A modern network architecture combines two or three of these protocols, each at the layer where it excels.
Field level — MQTT. A temperature sensor on an assembly line has neither the RAM nor the bandwidth for HTTP. MQTT QoS 1 on Mosquitto at the edge, bridged to EMQX in the cloud, is the golden path for industrial IoT in 2026. Add MQTT over QUIC if your devices move (vehicles, drones, AGVs).
Integration level — AMQP. Your SAP ERP publishes manufacturing orders. Your MES consumes them. Your quality system gets a copy. Complex conditional routing with persistent queues and dead-letter queues is AMQP’s home turf on RabbitMQ 4.x. Do not try this with MQTT — hierarchical topics do not replace routing-key exchanges.
Infrastructure level — NATS. You have three factories, two data centers, and a Kubernetes cluster in the cloud. NATS in supercluster mode unifies everything into a single global namespace with sub-millisecond latency and zero bridge configuration. This is the platform team’s choice — messaging as a system utility: apt install nats-server, one config line, and it runs.
The verdict. If you manage fewer than 100,000 fixed sensors, deploy Mosquitto and stop there. If your devices are mobile or you exceed one million endpoints, build an EMQX cluster with MQTT over QUIC. If you are integrating enterprise applications with complex routing, RabbitMQ 4.x is the tool for the job. And if you are building a multi-site platform for your microservices, NATS deserves your first test — nothing is simpler to operate.
References
- MQTT Specification v5.0 — OASIS Standard, March 2019
- EMQX vs Mosquitto — Features, Scalability, and Use Cases Compared, EMQX Blog, June 2026
- Network Protocol Comparison 2026: DDS, MQTT, gRPC, Kafka, and Beyond, ZenDevy, April 2026
- Message Broker Comparison in IIoT: MQTT, Kafka, AMQP or NATS, i-flow
- RabbitMQ 4.0 Release Notes — Khepri Metadata Store, RabbitMQ Blog, February 2025
- NATS — Cloud Native, Open Source, High-performance Messaging
- Eclipse Mosquitto — An Open Source MQTT Broker
- EMQX — The World’s #1 Open Source Distributed MQTT Broker