MQTT vs OPC UA: Which Protocol Should You Use for Industrial IoT?
Every IIoT architecture decision eventually arrives at the same question: MQTT or OPC UA? Both are legitimate, production-proven protocols with massive industry backing. Both have vocal advocates who'll tell you the other one is wrong. And both are almost certainly present in your future IIoT stack — because the real answer is "both, in different layers."
This guide breaks down the engineering trade-offs so you can make the right choice for your specific manufacturing environment, not based on vendor marketing, but on what actually works at the protocol level.
The Fundamentals: What Each Protocol Actually Does
MQTT (Message Queuing Telemetry Transport)
MQTT is a lightweight publish/subscribe messaging protocol originally designed by IBM in 1999 for satellite telemetry. It was built for constrained environments — low bandwidth, unreliable networks, small devices.
Architecture: Publish/Subscribe with a central broker
- Publishers send messages to topics (e.g.,
plant1/line3/machineA/temperature) - Subscribers listen to topics they care about
- A broker (e.g., Mosquitto, HiveMQ, EMQX) routes messages between publishers and subscribers
Key characteristics:
- Binary protocol with minimal overhead (as little as 2 bytes per packet header)
- Three Quality of Service (QoS) levels: 0 (at most once), 1 (at least once), 2 (exactly once)
- Retained messages (new subscribers get the last value immediately)
- Last Will and Testament (broker notifies subscribers if a client disconnects ungracefully)
- Built-in keep-alive mechanism
- Runs over TCP/IP, with TLS for security
Typical use case in IIoT: Edge gateway to cloud communication. The gateway collects PLC data and publishes it to an MQTT broker in the cloud.
OPC UA (Open Platform Communications Unified Architecture)
OPC UA is an industrial interoperability standard maintained by the OPC Foundation, released in 2008 as the successor to Classic OPC (COM/DCOM-based). It was built specifically for industrial automation.
Architecture: Client/Server with information models
- Servers expose structured data through an address space (like a hierarchical file system)
- Clients browse the address space, read/write values, and subscribe to changes
- The address space includes not just values but metadata — data types, engineering units, quality, timestamps
Key characteristics:
- Platform-independent (no more Windows COM/DCOM dependencies)
- Rich information modeling (object-oriented, with types, methods, events)
- Built-in security (X.509 certificates, signing, encryption)
- Discovery mechanism (clients can browse available data without prior configuration)
- Supports both polling and subscription-based data access
- Runs over TCP (binary, high performance) or HTTPS (firewall-friendly)
- Companion specifications for specific industries (PLCopen, ISA-95, Euromap, PackML)
Typical use case in IIoT: PLC-to-edge communication. Siemens S7-1500s, for example, have a built-in OPC UA server. Your edge gateway connects as an OPC UA client to discover and subscribe to available data.
Head-to-Head Comparison
| Criteria | MQTT | OPC UA |
|---|---|---|
| Architecture | Pub/Sub (broker-based) | Client/Server (direct) |
| Overhead | Minimal (2-byte header) | Higher (structured payloads) |
| Bandwidth | Very low (optimized for constrained networks) | Moderate to high |
| Information modeling | None (payload is opaque bytes) | Rich (types, units, quality, hierarchy) |
| Discovery | None (you must know the topic structure) | Built-in (browse the address space) |
| Security | TLS (transport-level) | TLS + X.509 certificates + signing + encryption (application-level) |
| Interoperability | Universal (any device that speaks TCP) | Industrial-focused (PLC and SCADA ecosystem) |
| Scalability | Excellent (brokers handle millions of connections) | Good (depends on server implementation) |
| Standardization | OASIS standard, ISO/IEC 20922 | OPC Foundation standard, IEC 62541 |
| PLC support | Rare (few PLCs have native MQTT clients) | Growing (Siemens, Beckhoff, B&R, CODESYS) |
| Edge gateway support | Universal | Universal |
| Payload format | Any (JSON, Protobuf, binary, CSV) | Defined by information model |
| Latency | Very low (sub-millisecond possible) | Low (1-10ms typical) |
When to Use MQTT
✅ Edge-to-Cloud Communication
MQTT's sweet spot is the link between your factory floor and the cloud. Edge gateways (like those used by MachineCDN) collect data from PLCs using industrial protocols (Ethernet/IP, Modbus, OPC UA) and then forward that data to the cloud over MQTT.
Why MQTT wins here:
- Low bandwidth: Cellular connections often have limited bandwidth. MQTT's minimal overhead means more data per byte.
- Unreliable networks: QoS 1 and 2 guarantee message delivery even with intermittent connectivity. Combined with store-and-forward on the gateway, you don't lose data during network drops.
- Scalability: When you have thousands of edge devices, MQTT brokers handle the fan-in efficiently.
- Firewall-friendly: MQTT uses a single outbound TCP connection. No incoming ports need to be opened.
✅ Constrained Devices and Sensors
Wireless sensors, environmental monitors, and small embedded devices benefit from MQTT's minimal resource requirements. An MQTT client can run in 10 KB of RAM, making it feasible on microcontrollers.
✅ Multi-Consumer Data Distribution
The pub/sub model means multiple consumers can receive the same data without the producer knowing about them. Your dashboard, your predictive maintenance engine, your data lake, and your alerting system can all subscribe to the same topics independently.
✅ Heterogeneous Device Fleets
When you have devices from dozens of different manufacturers — PLCs, sensors, meters, cameras, environmental monitors — MQTT provides a common communication layer without requiring every device to implement a specific information model.
When to Use OPC UA
✅ PLC-to-Edge Communication
When your PLC has a native OPC UA server (Siemens S7-1500, Beckhoff TwinCAT, B&R Automation Studio, CODESYS-based PLCs), use OPC UA to read data at the source. The structured address space means your edge gateway can discover available data points without manual tag configuration.
✅ Industrial Interoperability
When you need to exchange data between different industrial systems — PLCs from different vendors, SCADA systems, MES platforms — OPC UA's information model ensures both sides understand not just the value, but the meaning of the data.
✅ Complex Data Structures
If you need to exchange structured objects (not just flat values), OPC UA's object-oriented information model handles it natively. A "Machine" object can contain "Components" which contain "Parameters" with engineering units, quality indicators, and timestamps — all self-describing.
✅ Regulated Industries
Pharmaceutical (FDA 21 CFR Part 11), aerospace (DO-178C), and nuclear environments often require formal data integrity guarantees, audit trails, and application-level security. OPC UA's built-in security model with X.509 certificates, message signing, and encryption meets these requirements at the protocol level.
The Real Answer: Use Both (Hybrid Architecture)
The most effective IIoT architectures use both protocols in their appropriate layers:
[PLCs] ← OPC UA / Ethernet/IP / Modbus → [Edge Gateway] ← MQTT → [Cloud Platform]
Layer 1 (OT): OPC UA or native PLC protocols (Ethernet/IP, Modbus TCP/RTU) for device-to-edge communication. Use whatever protocol your PLC supports natively.
Layer 2 (Edge-to-Cloud): MQTT for gateway-to-cloud communication. Low overhead, reliable delivery, scalable, cellular-friendly.
Layer 3 (Cloud): Internal microservice communication — MQTT, Kafka, or whatever your cloud platform uses internally.
This is exactly the architecture MachineCDN uses. The edge gateway speaks native PLC protocols (Ethernet/IP, Modbus) to collect data directly from controllers, then uses MQTT over cellular to transmit data to the cloud. This hybrid approach gives you the best of both worlds — deep PLC integration at the edge, lightweight and reliable cloud communication.
Sparkplug B: The Best of Both?
Sparkplug B is a specification built on top of MQTT that adds OPC UA-like structure to MQTT messages. Developed by Cirrus Link (now part of Inductive Automation), Sparkplug B defines:
- Standard topic namespace:
spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id} - Structured payloads using Google Protobuf (more efficient than JSON)
- Birth/death certificates for automatic device registration and state tracking
- Metric definitions with data types, units, and timestamps
- Store-and-forward semantics
The appeal: You get MQTT's lightweight transport with structured data semantics. Your MQTT broker becomes IIoT-aware.
The reality: Sparkplug B adds complexity to the MQTT layer. If you're using a purpose-built IIoT platform, the platform already handles data modeling and structure — Sparkplug B solves a problem you don't have. It's most valuable in DIY architectures where you need interoperability between multiple edge vendors without a unifying platform.
Performance: Real-World Numbers
Based on typical manufacturing deployments:
MQTT Performance
| Scenario | Messages/sec | Latency | Bandwidth |
|---|---|---|---|
| Single edge gateway, 100 tags | 10-20 msg/s | under 100ms | 5-20 KB/s |
| 10 gateways, 1,000 tags total | 100-200 msg/s | under 200ms | 50-200 KB/s |
| 100 gateways, 10,000 tags | 1,000-2,000 msg/s | under 500ms | 0.5-2 MB/s |
| HiveMQ broker (single node) | 200,000+ msg/s | under 10ms | Network-limited |
OPC UA Performance
| Scenario | Items/sec | Latency | Notes |
|---|---|---|---|
| Siemens S7-1500, 500 tags | 500-2,000 items/s | 10-50ms | Subscription-based |
| Beckhoff TwinCAT, 1,000 tags | 1,000-5,000 items/s | 5-20ms | Binary transport |
| Unified Automation SDK | 10,000+ items/s | under 5ms | High-performance implementation |
For most manufacturing monitoring use cases (1-second sample rates, hundreds to thousands of data points), both protocols have ample performance headroom. Performance only becomes a differentiator at very high frequencies (sub-100ms) or very large scale (100,000+ data points).
Security Comparison
MQTT Security
MQTT relies primarily on transport-level security:
- TLS 1.2/1.3: Encrypts the connection between client and broker
- Username/password: Basic authentication
- Client certificates: Mutual TLS for device authentication
- ACLs: Topic-level access control on the broker
Gap: MQTT has no built-in payload security. If you need to prove that a specific device sent a specific message with specific content, you need to add application-level signing yourself.
OPC UA Security
OPC UA has application-level security built into the specification:
- X.509 certificates: Every client and server has a certificate
- Message signing: Every message can be signed to prove authenticity
- Message encryption: Payload encryption independent of transport
- Security policies: Three levels (None, Sign, SignAndEncrypt)
- User authentication: Certificates, username/password, or anonymous
- Audit trail: Built-in audit event logging
For manufacturing: If regulatory compliance requires message-level integrity (not just transport encryption), OPC UA's security model is more complete. For most IIoT monitoring use cases, MQTT with TLS and client certificates is sufficient.
Making the Decision
| If Your Priority Is... | Choose |
|---|---|
| Getting data to the cloud quickly | MQTT |
| Connecting to modern PLCs (Siemens, Beckhoff) | OPC UA at the device level |
| Minimizing bandwidth (cellular connections) | MQTT |
| Regulatory compliance (pharma, nuclear) | OPC UA |
| Connecting legacy equipment (Modbus) | Neither — use Modbus directly, then MQTT to cloud |
| Scalability (1,000+ devices) | MQTT |
| Plug-and-play interoperability between vendor systems | OPC UA |
| DIY architecture with multiple edge vendors | Sparkplug B (MQTT-based) |
| Purpose-built IIoT platform | Both (platform handles protocol abstraction) |
The Practical Recommendation
Don't overthink this. If you're using a modern IIoT platform, the protocol choice is abstracted away from you:
- The platform's edge gateway connects to your PLCs using whatever protocol they speak (Ethernet/IP, Modbus, OPC UA)
- The gateway transmits data to the cloud using MQTT (or a similar lightweight protocol) over cellular or Ethernet
- You interact with dashboards, alerts, and analytics — the protocol layer is invisible
MachineCDN handles this abstraction. You connect the gateway to your PLC, and data flows. Whether that PLC speaks Modbus RTU, Ethernet/IP, or OPC UA, the experience is the same: 3-minute setup, real-time data, predictive maintenance from day one.
If you're building a custom IIoT architecture, use the hybrid approach: native protocols at the device layer, MQTT at the transport layer, and structure your cloud ingestion pipeline to handle both.
Related reading: