OPC-UA vs MQTT for Industrial IoT: Which Should You Choose
OPC-UA and MQTT are not direct competitors. They solve different problems. OPC-UA is a rich industrial integration protocol with complex data modeling, method calls, events, and a sophisticated security model. MQTT is a lightweight publish/subscribe transport optimized for moving data from thousands of edge devices to central systems. The question is not which protocol is better — the question is which protocol fits your application.
If you are building a plant-floor HMI that talks to PLCs, OPC-UA is probably the right choice. If you are building a cloud platform that ingests data from 500 remote sites, MQTT is probably the right choice. If you are building an edge gateway that translates Modbus to something cloud-friendly, you might use both — OPC-UA to talk to the PLCs, MQTT to talk to the cloud.
This comparison is for engineers who need to make this decision. No marketing fluff, just the technical trade-offs.
OPC-UA: Rich Integration for Plant-Floor Systems
OPC-UA (OPC Unified Architecture) is the successor to OPC Classic (COM-based DCOM). It is a service-oriented protocol with a rich data model, complex types, methods, events, and a comprehensive security stack. OPC-UA was designed for plant-floor SCADA and HMI applications where you need to represent complex industrial processes, not just move time-series data.
Key OPC-UA Characteristics
Rich Address Space: OPC-UA servers expose a hierarchical address space of nodes, references, and attributes. You can model complex relationships: a boiler contains temperature sensors, the sensors have configuration parameters, the parameters have engineering units and limits. This address space is browsable, discoverable, and self-documenting.
Complex Data Types: OPC-UA supports structures, arrays, enumerations, and custom types. You can define a data structure that represents a complete motor profile (speed, torque, current, temperature, status bits) and read it as a single variable. Modbus and raw MQTT cannot do this — they only understand flat arrays of basic types.
Method Calls: OPC-UA allows clients to call methods (functions) exposed by the server. You can call a "StartMotor" method with parameters, not just write to a register. This enables RPC-style interactions where the client and server share a semantic interface, not just a data exchange.
Events and Alarms: OPC-UA has a built-in event and alarm model. Servers can push notifications to clients when conditions change: "Motor Overtemp Alarm Active", "Tank Level High Warning". Clients subscribe to event types and receive real-time notifications. No need for clients to continuously poll and compare thresholds.
Security Model: OPC-UA has encryption, authentication, and authorization built into the protocol. X.509 certificates, user authentication, role-based access control, encrypted channels. This is not bolted on — it is part of the specification. This makes OPC-UA suitable for plant-floor environments where security matters but OT networks are segregated.
Client/Server Model: OPC-UA uses a client/server architecture where clients initiate connections and servers respond. Sessions are maintained, subscriptions are persistent, and the server tracks which clients are interested in which data. This enables efficient data change notifications without continuous polling.
MQTT: Lightweight Transport for Edge-to-Cloud
MQTT (Message Queuing Telemetry Transport) is a publish/subscribe protocol designed for constrained devices and unreliable networks. It is tiny, fast, and efficient. An MQTT client can run on a microcontroller with 64KB of RAM. MQTT messages are minimal — a 2-byte header plus payload. This efficiency is why MQTT dominates IIoT platforms and cloud data ingestion.
Key MQTT Characteristics
Publish/Subscribe: MQTT uses a broker-based model where devices publish to topics and clients subscribe to topics. The broker routes messages from publishers to subscribers. This decouples data producers from data consumers — a temperature sensor publishes to plant/floor1/temperature, and multiple dashboards, historians, and alert systems subscribe without the sensor knowing who is listening.
Tiny Overhead: MQTT packets are minimal. The fixed header is 2 bytes. A typical publish message might be 10-20 bytes total. This is orders of magnitude smaller than OPC-UA messages. This efficiency matters on slow links (4G cellular, satellite) and on networks where bandwidth costs money.
Runs Anywhere: MQTT clients exist for every platform: microcontrollers, Linux gateways, Windows servers, cloud platforms, web browsers. The protocol is simple enough that a basic implementation is a few hundred lines of code. This ubiquity means you can deploy MQTT on devices that cannot run OPC-UA.
Horizontal Scaling: A single MQTT broker can handle tens of thousands of concurrent connections and millions of messages per second. Clustering allows multiple brokers to share load. This is why cloud platforms use MQTT — they can aggregate data from thousands of sites without managing thousands of point-to-point connections.
QoS Levels: MQTT defines three quality of service levels: QoS 0 (fire and forget), QoS 1 (at least once delivery), and QoS 2 (exactly once delivery). You choose the guarantee level per application. QoS 1 is typical for telemetry — it guarantees delivery but allows duplicates (easy to filter). QoS 2 is used for critical commands where duplicates are unacceptable.
Last Will and Testament: MQTT clients specify a "last will" message when they connect. If the client disconnects ungracefully (crashes, network drops), the broker publishes the last will message on behalf of the client. This provides instant notification of device failures without waiting for timeouts.
OPC-UA vs MQTT: Direct Comparison
Here is the side-by-side breakdown of the two protocols.
The pattern should be clear. OPC-UA wins on features and data modeling. MQTT wins on efficiency and scalability. The right choice depends on where you are in the architecture and what you are trying to do.
Sparkplug B: Making MQTT Stateful
Standard MQTT has no payload definition. You publish a byte array, and subscribers receive that byte array. The protocol does not tell you how to encode a temperature, how to represent quality, or how to handle device birth and death. This is where Sparkplug B comes in.
Sparkplug B is an MQTT payload specification defined by the Eclipse Foundation. It adds the industrial features that MQTT lacks:
- Data Definition: Sparkplug B defines how to encode tags, metrics, quality, and timestamps in MQTT payloads. It is a self-describing binary format that includes data types, metadata, and quality indicators.
- Birth/Death Certificates: When a Sparkplug device connects, it publishes a "birth" message that declares its data model. When it disconnects gracefully, it publishes a "death" message. If it disconnects ungracefully, the broker's last will publishes a death message. This allows subscribers to track device online/offline status.
- Alias Compression: Sparkplug allows assigning numeric aliases to tag names. After the initial birth message, data messages use aliases instead of repeating tag names. This reduces bandwidth while maintaining self-description.
- Quality Indicators: Every metric in Sparkplug includes a quality code (good, stale, fault, etc.). This provides the same reliability information that OPC-UA includes in Status-Flags.
Sparkplug B bridges the gap between MQTT's lightweight transport and industrial data requirements. With Sparkplug, MQTT becomes stateful and self-describing like OPC-UA, while keeping MQTT's efficiency and scalability.
When to Choose OPC-UA
OPC-UA is the right choice when you need rich integration and complex data modeling on the plant floor.
Plant-Floor HMI/SCADA
If you are building an HMI or SCADA system that connects to PLCs, DCS systems, or industrial controllers, OPC-UA is the standard. Modern PLCs from Siemens, Rockwell, Schneider, and others expose OPC-UA servers. Your HMI connects to these servers, browses the address space, and reads/writes variables. The rich data model lets the HMI display complex hierarchies and structures without manual configuration.
Controller-to-Controller Communication
When PLCs need to exchange data directly, OPC-UA provides a standardized way to do this. Instead of mapping Modbus registers or configuring proprietary protocols, you expose OPC-UA servers on each PLC and let them communicate. The method call feature allows one controller to trigger operations on another.
Complex Data Structures
If your data cannot be represented as flat registers, OPC-UA is necessary. A motor drive profile with nested parameters, a recipe system with structured data, a batch process with complex state models — these are natural fits for OPC-UA's rich type system. Trying to represent these in flat Modbus registers or raw MQTT payloads is painful and error-prone.
Method Calls and RPC
If you need to call functions on a remote device, OPC-UA methods are the tool. You can call "StartMotor", "ResetAlarm", "ChangeRecipe", or any other operation with parameters. The client and server share a semantic interface, not just data exchange. This enables controller-like behavior over the network.
Secure Plant-Floor Integration
If you need security within the plant (encryption, authentication, authorization), OPC-UA provides this out of the box. You do not need to layer VPNs, TLS terminators, or custom authentication. The protocol handles it. This is critical for facilities that require compliance with security standards.
When You Run on Servers and Gateways
OPC-UA clients are heavy. They assume plenty of RAM, CPU, and storage. This is fine for servers, HMIs, and edge gateways. It is not fine for microcontrollers. If your application runs on Linux or Windows, OPC-UA is viable. If it runs on a constrained MCU, OPC-UA is not an option.
When to Choose MQTT
MQTT is the right choice when you need to move data from many edge devices to central systems, especially over unreliable networks.
Multi-Site Telemetry
If you have 50 remote sites pumping data to a central cloud platform, MQTT is the obvious choice. Each site has an MQTT client that connects to the cloud broker and publishes data. The cloud platform subscribes and processes data from all sites. Managing 50 OPC-UA server connections from a central cloud is complex and fragile. Managing 50 MQTT connections is straightforward.
Edge-to-Cloud Data Ingestion
When edge gateways need to push data to the cloud, MQTT's publish/subscribe model is ideal. The gateway publishes to topics like site/{id}/equipment/{id}/data. Cloud services subscribe to the topics they need. Adding new consumers (dashboards, historians, analytics) does not require changing the gateway — just subscribe to the topics.
Constrained Devices
MQTT runs on devices that cannot run OPC-UA. A microcontroller with 64KB of RAM can run an MQTT client. It cannot run an OPC-UA client. If your edge devices are sensors, RTUs, or small gateways, MQTT is the only viable option for direct connectivity. OPC-UA requires a gateway edge to translate MQTT to OPC-UA for plant-floor consumption.
Unreliable Networks
MQTT is designed for unstable connections. It handles reconnects, QoS-level delivery guarantees, and buffered messages. If a cellular link drops, the client reconnects and resumes. The broker can buffer messages for offline subscribers. This makes MQTT ideal for remote sites with 4G, satellite, or periodic connectivity.
Horizontal Cloud Platforms
Cloud platforms that serve multiple tenants need horizontal scalability. An MQTT broker cluster can handle tens of thousands of connections. Adding more capacity means adding more broker nodes. OPC-UA servers do not scale horizontally — they scale vertically. For cloud platforms aggregating data from many customers, MQTT is the clear winner.
When You Need a Simple Transport
If you just need to move bytes from A to B and you do not need methods, events, or complex data structures, MQTT's simplicity is an advantage. Less complexity means fewer bugs, easier debugging, and faster implementation. The trade-off is that you must define your own payload conventions (or use Sparkplug B).
The Hybrid Architecture: Use Both
In practice, most industrial IIoT architectures use both protocols. OPC-UA for plant-floor integration, MQTT for edge-to-cloud transport.
Typical Hybrid Pattern
- Plant Floor: PLCs and controllers expose OPC-UA servers. Local HMIs and SCADA systems connect via OPC-UA for real-time control and visualization.
- Edge Gateway: An edge gateway runs an OPC-UA client to connect to the PLCs and collect data. The gateway also runs an MQTT client (with Sparkplug B) to push data to the cloud.
- Cloud Platform: The cloud MQTT broker receives data from all gateways. Cloud services subscribe to topics, process data, store in databases, and expose dashboards.
- Backhaul: Cloud-initiated commands flow back through MQTT to the gateway, which translates them to OPC-UA method calls or writes to the PLCs.
This pattern gives you the best of both worlds. OPC-UA provides rich integration on the plant floor where bandwidth is plentiful and devices are powerful. MQTT provides efficient transport for edge-to-cloud where bandwidth is limited and devices are constrained. The edge gateway performs protocol translation.
Tools and Implementation
Both protocols have mature tooling and open-source implementations.
OPC-UA Tools
Voltrus OPC-UA Explorer provides native macOS browsing of OPC-UA servers. You can connect to any OPC-UA server, browse the address space, read and write variables, call methods, and subscribe to data changes. This is invaluable for debugging OPC-UA integrations and understanding how a server exposes its data model.
Open-source OPC-UA stacks exist for C++, .NET, Java, Python, and Node.js. The OPC Foundation provides reference implementations. Commercial SDKs are available from vendors with support and certification.
MQTT Tools
MQTT has a vibrant open-source ecosystem. Mosquitto is a popular open-source broker. EMQX and HiveMQ are commercial brokers with clustering and enterprise features. Client libraries exist for every programming language.
Voltrus MQTT Explorer provides native macOS tools for MQTT debugging. You can connect to any broker, subscribe to topics, publish messages, and monitor traffic. The client supports MQTT 5.0, SSL/TLS, and WebSocket connections.
Sparkplug B Tools
The Eclipse Tahu project provides open-source Sparkplug B implementations for Java, C, and Python. These libraries handle encoding and decoding Sparkplug payloads, making it easy to add Sparkplug support to your MQTT applications.
Frequently Asked Questions
When should I use OPC-UA vs MQTT?
Use OPC-UA for plant-floor SCADA integration where you need rich data modeling, complex address spaces, method calls, events, and secure plant-floor integration. Use MQTT for multi-site telemetry, edge-to-cloud data ingestion, and applications where bandwidth is limited and devices are resource-constrained. OPC-UA excels at controller-to-controller communication; MQTT excels at moving data from many edge devices to central systems.
What is Sparkplug B and why does it matter for MQTT?
Sparkplug B is an MQTT payload specification that adds data modeling, birth/death certificates, and alias compression to MQTT. Standard MQTT is just a transport — it doesn't define what the payload means. Sparkplug B defines how to encode industrial data (tags, metrics, quality) in MQTT messages, making MQTT stateful and self-describing like OPC-UA. Sparkplug B bridges the gap between MQTT's lightweight transport and industrial data requirements.
Is OPC-UA heavier than MQTT?
Yes, OPC-UA is significantly heavier than MQTT. A minimal OPC-UA client requires several megabytes of code and tens of megabytes of RAM. An MQTT client can run on microcontrollers with 64KB of RAM. OPC-UA uses a complex binary protocol with security layers, service calls, and session management. MQTT is a simple publish/subscribe protocol with tiny packets. This is why MQTT dominates edge devices and OPC-UA dominates servers and gateways.
Can MQTT replace OPC-UA in industrial automation?
MQTT can transport data that traditionally used OPC-UA, but it requires additional work. Without Sparkplug B, MQTT lacks the data modeling, complex types, and discovery that OPC-UA provides. With Sparkplug B, MQTT can provide similar statefulness and metadata, but you lose method calls, events, and complex address spaces. MQTT is better for data movement; OPC-UA is better for rich integration.
Why do IIoT platforms use MQTT?
IIoT platforms use MQTT because it scales horizontally to thousands of devices, has low overhead, runs on constrained hardware, and works well over unstable networks. MQTT's publish/subscribe model decouples data producers from consumers, allowing many devices to publish data simultaneously without managing thousands of point-to-point connections. This makes MQTT ideal for cloud platforms that aggregate data from many sites.
Explore Both Protocols on macOS
Voltrus provides native macOS tools for both protocols. OPC-UA Explorer for browsing servers, MQTT Explorer for broker debugging. Universal binaries, no JVM, $49 each or $79 for the bundle. Try them free for 14 days.
Explore OPC-UA and MQTT Tools