OPC UA vs. MQTT: Choosing the Right Protocol for Industrial IoT
Both protocols show up in nearly every IIoT architecture discussion, but they solve different problems. Here's how to decide which one — or both — belongs in your plant.
Two protocols, two different jobs
OPC UA and MQTT get lumped together constantly because both show up in nearly every Industrial IoT conversation, but they were built to solve different problems. OPC UA is an information modeling standard — it describes not just a data value, but what that value means, its data type, its relationships to other data, and how to securely browse and interact with it. MQTT is a lightweight publish/subscribe messaging protocol built for constrained networks and high device counts. Neither one replaces the other; in most well-designed architectures, they coexist at different layers.
Where OPC UA fits
OPC UA excels at the plant-floor-to-SCADA layer, where you need rich, self-describing data and strong built-in security between a limited number of well-connected industrial systems — PLCs, SCADA servers, and historians. Its structured address space makes it easy for a new engineer or a new system to browse and understand what data is available without external documentation.
Where MQTT fits
MQTT shines when you're moving data from a large number of distributed or resource-constrained devices — sensors, edge gateways, remote assets — up to a central broker, often over unreliable or bandwidth-limited networks. Its small message overhead and publish/subscribe model make it efficient at scale in a way that traditional polling-based protocols are not.
The practical answer: use both
Most modern IIoT architectures we design use OPC UA for structured, secure data exchange between core control and SCADA systems, and MQTT (often via the Sparkplug B specification) to move that same data efficiently out to cloud analytics platforms or across a large fleet of edge devices. The decision isn't OPC UA versus MQTT — it's which layer of your architecture each one belongs in.
What this means for your next IIoT project
Before selecting a protocol, map out your actual data flow: what's generating the data, what's consuming it, how many endpoints are involved, and what your network constraints are. That map will tell you where each protocol belongs far more reliably than a generic recommendation ever could.
More from the blog
Continue reading.
Have a question about applying this to your plant?
Our engineering team can walk through how these concepts apply to your specific equipment and constraints.