Anyone planning a messaging infrastructure for industrial IoT projects like the Unified Namespace (UNS) can’t avoid a message broker comparison: MQTT, Kafka, AMQP, or NATS – which broker fits? The four candidates pursue fundamentally different design goals: from lightweight field communication to high-throughput event streaming to cloud-native clustering. This article compares all four systematically using practice-relevant criteria in an IIoT context and shows which combination makes sense in the Unified Namespace (UNS).
Message Broker Comparison in IIoT: An Overview
Before diving into the direct comparison, it’s worth taking a quick look at each protocol’s original design goals. After all, these determine where it excels and where it hits its limits.
MQTT (Message Queuing Telemetry Transport)
MQTT was originally built for resource-constrained devices on unstable connections – satellite links, sensors, embedded systems. Its pub/sub model over a central broker, tiered QoS levels (QoS 0, QoS 1, QoS 2), minimal protocol overhead, and broad hardware support have made MQTT the de facto standard for the field level in Industrial IoT (IIoT). As an OASIS standard now at version 5.0, it ships natively in modern PLCs, gateways, and edge devices.
Apache Kafka
Apache Kafka is a distributed event-streaming platform built around log-based persistence. Messages land in topics as an immutable, ordered log, and consumers can read that log at any point in time. The design goal here is maximum throughput at high data volumes, not minimal latency. Kafka does demand significant infrastructure to operate and scale – a broker cluster running the KRaft consensus protocol – but nothing beats it when the job is processing millions of events per second, persistently.
AMQP (Advanced Message Queuing Protocol)
AMQP (Advanced Message Queuing Protocol) is an open enterprise messaging protocol, best known through RabbitMQ. Its strength lies in flexible routing mechanisms: exchanges, queues, and bindings enable complex message flows – topic-based routing, header-based routing, fanout. Acknowledgements and dead-letter queues ensure reliable delivery even when processing fails. AMQP is built for enterprise application integration, not mass telemetry.
NATS
NATS is a cloud-native, high-performance messaging system designed for simple operations and global scale. The NATS server is a single binary with no external dependencies. Native clustering and superclusters let you merge multiple clusters across sites and continents into one unified namespace. With JetStream – the persistent extension of NATS – retention policies, consumer groups, and effectively-once delivery are available. Latency and overhead sit at MQTT levels, while operational complexity stays well below Kafka’s.
Technical Comparison: MQTT, Kafka, AMQP, and NATS
The following table shows the key criteria in a direct message broker comparison:
| Criterion | MQTT | Apache Kafka | AMQP / RabbitMQ | NATS |
|---|---|---|---|---|
| Latency | very low (<5 ms) | medium–high (10–100 ms) | low–medium (<10 ms) | very low (<1 ms) |
| Throughput | medium | very high (millions of events/s) | medium | high |
| Persistence | limited (retained messages) | strong (configurable log retention) | medium (queues, TTL) | strong (JetStream) |
| Protocol Overhead | minimal (2-byte fixed header) | high | medium | minimal |
| Edge Suitability | very good | poor | medium | good |
| OT Device Support | very good (native in PLCs, gateways) | none | low | via bridge/SDK |
| Clustering / Scaling | limited (vendor-dependent, not native) | strong (Kafka cluster) | medium (RabbitMQ cluster) | strong (native clustering + supercluster) |
| Ops Complexity | low | high | medium | low |
| Security / Auth | TLS, username/password, optional mTLS – broker ACLs for topic permissions | TLS, SASL (SCRAM, Kerberos, OAuth), native ACLs – enterprise-grade | TLS, SASL, granular vHost/permission model, LDAP integration | TLS, mTLS, NKeys/JWT-based decentralized auth with account isolation |
| Primary Use Case | Field level, OT devices | Stream processing, analytics | Enterprise application integration | UNS backbone, cloud/edge bridging |
Message Broker Comparison: What the Results Mean in Practice
Three rows matter most for IIoT architectures: edge suitability, OT device support, and ops complexity. Kafka is out for direct field communication – running a Kafka cluster on an edge gateway makes sense neither in terms of resources nor operations. AMQP is rarely natively available for OT devices. MQTT and NATS share the lead here – with the difference that MQTT already ships inside OT hardware, while NATS plays out its strengths at the infrastructure level.
On the security side, the four candidates differ mainly in their auth model: MQTT and AMQP rely on classic broker ACLs (username/password, optional client certificates), while Kafka and NATS offer more granular, modern mechanisms via SASL/native ACLs or NKeys/JWT. In practice, however, it’s often the weakest link at the field level that decides the outcome: many legacy OT devices don’t support TLS, so network segmentation (VLANs, firewalls, a DMZ between OT and IT) forms the actual security boundary – regardless of which protocol runs at the application level.
Summary: Message Broker Comparison at a Glance
Further Reading
If you’d like to look at the differences between the individual communication protocols and broker technologies in more depth, the following articles offer detailed comparisons:
- Kafka in Industrial IoT vs. MQTT
- NATS vs. MQTT: Which Protocol Fits Best in a Unified Namespace
- NATS vs. Kafka: Comparison for the Unified Namespace (UNS)
Use Cases in IIoT
MQTT: Shop-Floor Communication with MQTT-Enabled Devices
MQTT is the right choice when OT devices support it natively – and that’s increasingly the case for modern PLCs, gateways, and sensors. Minimal protocol overhead, reliable delivery via QoS levels, and broad hardware compatibility make MQTT the optimal choice for direct device communication at the field level. Crucially: MQTT is primarily a device communication protocol, not an infrastructure protocol for the UNS backbone. Where devices don’t speak native MQTT, protocol gateways (e.g. Modbus-to-MQTT, OPC UA-to-MQTT) handle the translation.
NATS: UNS Backbone and Multi-Site Infrastructure
NATS is particularly well suited to serving as the central messaging infrastructure for the Unified Namespace (UNS). Native clustering with no external dependencies, sub-millisecond latency, and supercluster capability – merging multiple geographically distributed clusters into one unified global namespace – are properties that none of the other three protocols offer in this combination. With JetStream, retention policies can be configured per subject, so critical process data stays persistent while telemetry data with a short TTL gets discarded. NATS is also well suited for cloud-edge bridging: messages can be replicated transparently from the edge cluster to the cloud cluster, with no changes to application logic.
Apache Kafka: Stream Processing and Analytics Layer
Apache Kafka isn’t suited for the field level, but it’s unbeatable when it comes to downstream processing of large data volumes. Typical use cases in IIoT: ingestion into data lakes or data warehouses, stream processing with Kafka Streams or Apache Flink, historical analysis of production data, machine learning pipelines. Integration typically happens via a Kafka connector that subscribes to messages from the UNS backbone (NATS or MQTT) and writes them into Kafka topics. Kafka is not a replacement for the UNS backbone, but a specialized addition for applications with high persistence and throughput requirements.
AMQP / RabbitMQ: Enterprise Application Integration
AMQP, or more specifically RabbitMQ, occupies a specific niche: complex routing requirements in enterprise applications. When SAP systems, MES, or ERP applications need to process messages differently based on header values, routing keys, or application logic, AMQP offers mature mechanisms for this. In an IIoT context, AMQP typically acts as a bridge between the UNS and IT-side applications – not as the primary transport protocol for OT data.
Which Message Broker Fits the Unified Namespace (UNS)?
The Unified Namespace (UNS) places specific demands on the messaging infrastructure: hierarchical topics, pub/sub semantics, low latency, scalability across edge and cloud, simple operations, and the ability to span a unified global namespace across multiple sites.
NATS as the primary UNS protocol is the only one of the four candidates that fully meets these requirements:
- Hierarchical subjects: NATS subjects follow dot notation (enterprise.site.area.line.machine.signal) and support wildcards (* for one level, > for all sub-levels) – mirroring the ISA-95 hierarchy.
- Native clustering: Multiple NATS servers form a cluster without an external coordination layer. Scaling horizontally simply means adding another server.
- Supercluster / leaf nodes: NATS superclusters merge multiple clusters into one global namespace. Leaf nodes let edge sites run as autonomous units that selectively replicate into the central cluster – ideal for distributed production sites.
- JetStream: Persistent delivery, consumer groups, and replay functions built directly into NATS, with no additional middleware.
- Ops simplicity: A single binary, no external dependencies, declarative configuration.
MQTT at the field device – bridged to NATS: Where OT devices speak native MQTT, it remains the preferred channel for field communication. An MQTT-to-NATS bridge connector (e.g. via i-flow Edge) translates incoming MQTT topics into NATS subjects and feeds the data seamlessly into the UNS. This isn’t a limitation, but a proven pattern: the right protocol in the right place, connected by a lightweight bridge.
Kafka downstream: When production data needs to flow from the UNS into analytical systems, a Kafka connector is the clean solution. The UNS backbone stays lean and latency-optimized, while Kafka handles long-term persistence and stream-processing tasks.
AMQP / RabbitMQ has no place at the UNS core – the routing complexity isn’t needed for OT data flows, and native OT device support is missing. As a bridge to enterprise IT applications, however, AMQP remains a valid option.
Decision Guide: Message Broker Comparison
The following overview helps with protocol selection in a concrete project context:
- Connecting OT devices with native MQTT directly: → MQTT for field communication, bridged to NATS for the UNS.
- UNS backbone for one or more sites: → NATS with clustering. For multiple sites: NATS superclusters or leaf nodes.
- Historical data analysis, data lakes, ML pipelines: → Apache Kafka as a downstream analytics layer, fed from the UNS.
- Enterprise applications with complex routing requirements: → AMQP / RabbitMQ for IT-side integration, e.g. connecting SAP or MES.
- Cloud-edge bridging with autonomous edge sites: → NATS leaf nodes at the edge, a central NATS cluster in the cloud.
- Modern greenfield architecture with no legacy OT devices: → NATS end-to-end as a single protocol across all layers.
The most proven pattern in practice: MQTT at the field device → bridge → NATS as the UNS backbone → Kafka for analytics. Each protocol handles exactly the job it was designed for.
Conclusion
No single protocol wins the message broker comparison across the board – the real question isn’t MQTT, Kafka, AMQP, or NATS, but which protocol fits which layer of the architecture. In an IIoT context, the answer follows a clear structure:
- Field level: MQTT remains the first choice wherever OT devices support the protocol natively – lightweight, widely adopted, proven in hardware.
- UNS backbone: NATS is the superior infrastructure for the Unified Namespace – native clustering, superclusters for global namespaces, JetStream for persistence, minimal operational overhead.
- Analytics and persistence: Apache Kafka as a specialized downstream layer for stream processing and long-term persistence.
- Enterprise IT integration: AMQP / RabbitMQ for application-side routing requirements in IT systems.
