OPC UA vs. MQTT: Which Protocol Is Best for What?
In short: OPC UA connects, while MQTT decouples. OPC UA is a service-oriented protocol for standardized, secure access to machine and plant data—a client makes a targeted request to a server. MQTT is an event-driven publish/subscribe protocol: data sources and data recipients are not aware of each other; a broker mediates between them. Both protocols are open standards, and both transmit structured data—the difference lies in the communication pattern, not in their value.
That is why the practical answer is rarely „either—or“: OPC UA for access and data acquisition at the machine, MQTT for distribution and integration with IT and the cloud. Combining the two results in an architecture that provides end-to-end support, from the shop floor all the way to the cloud.
The external link to the video accompanying the article: Lunch Talk – OPC UA vs. MQTT on YouTube
The key question: Who is addressing whom?
The key difference between the two protocols is the question of who initiates the communication and who needs to know whom.
At OPC UA There is a directed relationship: A client establishes a session with a server, navigates through its address space, reads values, writes parameters, and subscribes to changes. The client knows which machine it is communicating with. This is ideal when you want to access a specific system, and it requires that both sides be accessible.
At MQTT This relationship does not exist. A publisher sends data to a topic on the broker and does not know who is reading it. A subscriber subscribes to a topic and does not know where the data comes from. The sender and receiver are decoupled in terms of time, space, and technology. New data recipients can be added without having to make any changes at the source.
It is precisely this decoupling that makes MQTT the foundation of modern data architectures such as the Unified Namespace, in which the broker maps a company's structured, semantically named data space. MQTT is thus much more than just a transport protocol.
The Strengths of OPC UA – With Real-World Examples
Semantics Instead of Raw Data
An OPC UA server does not just return the number 73.4, but also the following information: spindle temperature, degrees Celsius, timestamp, quality code, and associated machine. This structure is part of the protocol and does not need to be maintained later in a mapping table.
Example: A machine tool manufacturer provides its equipment via the umati Companion Specification. An MES can retrieve order status, tool life, and malfunctions without having to develop a separate data model for each machine.
Writing, not just reading
OPC UA is bidirectional and supports method calls. You can set setpoints, transfer recipes, and initiate processes.
Example: A production order is created in the ERP system; the recipe parameters are sent to the filling line via OPC UA; the plant operator acknowledges receipt—eliminating the need for paper and manual data entry entirely.
Safety Right from the Factory
Certificate-based authentication, encrypted communication, and fine-grained access control are integral parts of the specification, not additional work for the project.
Example: In a regulated production environment, it must be possible to trace which service changed which parameter. With OPC UA, this can be achieved without an additional intermediate layer.
Alarms, Events, and Diagnostics
Conditions, limit violations, and acknowledgments are provided for in the model.
Example: A maintenance system subscribes to alerts from multiple systems and automatically generates tickets that include system context and error codes.
The Strengths of MQTT – With Real-World Examples
One data stream, any number of recipients
A value is published once and is immediately available to all interested systems. New recipients are added without any changes being made at the source.
Example: The production figures for a line are first sent to the broker. From there, they feed the shop floor dashboard, the cloud data platform, and the quality analysis system—three consumers, one connection.
Reliable Even on Unstable Networks
Low overhead, quality-of-service levels, and buffering make MQTT resilient in situations where connections are unstable or bandwidth is limited.
Example: A fleet of machines at multiple locations transmits energy and status data to headquarters via cellular networks. If a connection is briefly lost, no data is lost.
Scaling Across Plants and Locations
A uniform topic tree reflects the organizational structure—company, plant, division, line, machine, key metric.
Example: In the Unified Namespace, the OEE values for all plants are organized under the same topic logic. This means that a cross-site analysis is simply a matter of setting up a subscription, not a new integration project.
Event-driven rather than cyclical
It is sent when something changes—not because a polling interval expires. This reduces load and shortens response times.
Example: A fault report reaches the maintenance team on their mobile device the moment it occurs, without the system checking every second.
When do you use which protocol?
OPC UA, if…
- You need structured access to machine and plant data
- You need semantic information—entities, alerts, statuses, methods
- You want to write data back to the system, configure parameters, or trigger processes
- Security and user management should be integrated
- Focus on engineering, diagnostics, or commissioning
MQTT, if…
- You want to distribute data efficiently to many recipients
- You need to connect numerous systems, plants, and locations
- You are working with low bandwidth or unstable networks
- You implement cloud, IoT, or analytics scenarios
- You need an architecture that can scale without modifying the source code
Interaction in Practice
In most production environments, a robust architecture results from the combination of both protocols:
Field level – Sensors, PLCs, robots, CNC machines → OPC UA Server – Structured, semantic access to machine data → Edge / Gateway – Processing, aggregation, contextualization → MQTT Broker – Distribution based on the publish/subscribe principle → Cloud & Data Platform, MES/ERP, Dashboards, AI & Analytics
This is exactly where our products come into play: kepware and the OPC Router connect the systems and translate between the protocol worlds, manubes and pronubes make the data usable—as real-time visualizations, as data models, and as a basis for decision-making. The protocol issue thus becomes an architectural decision, not a matter of faith.
Conclusion
OPC UA and MQTT are not competitors. They address different needs: OPC UA addresses the need for structured, secure access to machinery, while MQTT addresses the need for decoupled, scalable distribution within an enterprise. OPC UA connects. MQTT decouples. Those who use both in the right places lay the foundation for seamlessly connected, intelligent production—and thus for smart production.
Would you like to learn more?
In our Lunch Talk Video: „OPC UA vs. MQTT“ Let's walk through the topic using specific architectural examples and answer your questions live. Reserve your spot now—or contact our experts directly.
| Criterion | OPC UA | MQTT |
|---|---|---|
| Communication Patterns | Client/server, service-oriented (plus PubSub starting with OPC UA 1.04) | Publish/Subscribe via a Broker |
| Coupling | Point-to-point connection; client knows the server | Completely decoupled via topics |
| Data Model | Semantic Information Model in the Address Space: Types, Units, Status, Alarms, Methods | Topic Structure; Semantics via Conventions or Sparkplug B |
| Security | Integrated: Certificates, Encryption, Authentication, Rights Management | TLS encryption, authentication at the broker; permissions per topic |
| Overhead | Higher – detailed protocol, binary over TCP | Very small—minimal header, ideal for low bandwidths |
| Scaling | Per connection; a large number of clients increases the server load | Very good—one data stream, any number of subscribers |
| What to Do in Case of Power Outages | Session has been terminated; reconnection is required | Buffering, QoS Levels, Last Will & Testament |
| Typical location of use | Field and Control Levels, Close to OT | Across locations, edge, cloud, IT-centric |
| Standard | IEC 62541 (OPC Foundation) | ISO/IEC 20922 (OASIS) |
| Standard Port | 4840 | 1883 (8883 with TLS) |
| In a nutshell | Connects specifically and describes completely | Decoupled, clean, and efficiently distributed |
