So, I’ve lost count of how many times someone’s asked me, “Henry, should I use MQTT or OPC UA for my manufacturing project?” The truth is, I’ve been on both sides of that decision — sometimes sweating over a flaky network at 2 a.m., sometimes smiling as data flows smoothly from the shop floor to the cloud. Here’s what I’ve really learned, no fluff.
The Real Question: What Are You Trying to Do?
The most important thing is not which protocol is “better,” but what problem you’re actually solving. MQTT and OPC UA are both great, but in different ways. I used to think it was all about features, but after years in plants and boardrooms, I know it’s about fit. Are you connecting thousands of sensors across a big site, streaming data up to the cloud, or do you need deep, structured integration with your automation layer and legacy systems?
MQTT: Fast, Simple, and Cloud-Ready
Let me start with MQTT. It’s like the workhorse for getting lots of real-time data from point A to point B — especially if you want to push it to the cloud. It’s lightweight, so it doesn’t bog down your edge gateways or network. That’s why, in one big project, we picked MQTT with a Unified Namespace (UNS) and Quality of Service 1 (QoS 1): we needed reliable, at-least-once delivery for real-time telemetry, and MQTT just worked. It handled network hiccups, buffered when the cloud link dropped, and played nicely with our edge stack and ISA-95 hierarchy.
But MQTT isn’t perfect. It’s not great for sending huge payloads or for scenarios where you need rich, contextualized data models right out of the box. And if you’re in a regulated environment (GxP, for example), you need to be careful with QoS settings — QoS 0 won’t cut it for compliance, even if it’s faster
Also, MQTT’s security and access control are solid these days (TLS, mutual auth), but it’s not as deeply integrated into the automation layer as OPC UA.
OPC UA: Deep Integration, Rich Data, but Heavier
Now, OPC UA is the king when you want structured, contextualized data and tight integration with PLCs, SCADA, and DCS systems. It’s designed for industrial automation, so you get data types, metadata, browsing, and even methods (not just values). In one metals plant, we used OPC UA to connect to a legacy DCS — it was the only way to get structured data out, with all the context we needed for MES and analytics.
But — and this is a big but — OPC UA can be heavier on resources. It’s not as easy to scale to thousands of edge devices, especially over unreliable networks. In my experience, OPC UA works best inside the plant, close to the machines, or when you need to pull rich, structured data into your MES or historian. For edge-to-cloud, it’s sometimes overkill and harder to maintain, especially if your team isn’t deep into automation protocols.
When I Choose Each (A Real Example)
A few years ago, I led a multi-site IIoT rollout for a global manufacturer. The goal was to get real-time data from hundreds of lines into a cloud analytics platform, but also to support local MES and historian needs. Here’s what we did:
- On the shop floor, we used OPC UA to connect to PLCs and DCS, because we needed structured data and tight integration with automation.
- At the edge gateway, we translated that data into MQTT (with UNS and QoS 1), which sent telemetry up to the cloud. This kept things lightweight and scalable, and made it easy to plug into cloud-native tools.
For GxP-critical data, we made sure to use QoS 1, with buffering and store-and-forward, so nothing got lost if the network went down. We did performance tests — MQTT handled 100k messages per second without breaking a sweat, as long as payloads were small and the broker was sized right.
We did run into issues: integrating legacy systems was tricky, especially when some older equipment only spoke OPC DA or proprietary protocols. We had to use protocol converters and sometimes live with less-than-perfect mapping. And, maintaining OPC UA servers across so many sites took real effort — more than MQTT brokers, honestly.
What I’ve Learned (And What Matters Now)
If you want my honest advice, don’t pick just one. Use OPC UA where you need deep integration and rich data models, typically inside the plant. Use MQTT for scalable, real-time telemetry and cloud integration, especially when you need to connect lots of devices or sites. If you’re building a Unified Namespace, MQTT is your friend — just be careful with QoS and compliance.
One unpopular opinion: I think too many folks try to force everything into OPC UA because it’s “standard,” but end up with heavy, hard-to-maintain architectures. MQTT is simpler, faster, and good enough for most telemetry — but you still need OPC UA somewhere in your stack. And, don’t underestimate the cost and complexity of maintaining a big OPC UA deployment compared to MQTT.
The Takeaway
Pick the protocol that fits your problem, not the other way around. MQTT for fast, scalable telemetry; OPC UA for rich, structured integration. Most real plants need both — and that’s okay.
Leave a Comment