If you are evaluating communication protocols for a manufacturing IoT project, two names dominate the conversation: MQTT and OPC-UA. Both are proven in production environments. Both have large ecosystems. And both solve the same fundamental problem — getting data from machines to the systems that need it.
But they take fundamentally different approaches. MQTT was designed as a lightweight messaging transport. OPC-UA was designed as a comprehensive industrial interoperability framework. That difference in philosophy shapes everything: bandwidth consumption, cloud readiness, deployment complexity, and the types of architectures each protocol enables.
This article breaks down both protocols honestly — strengths, weaknesses, and the real-world scenarios where each one makes sense. We will also cover the increasingly common pattern of using both together.
MQTT (Message Queuing Telemetry Transport) was created in 1999 by Andy Stanford-Clark at IBM for monitoring oil pipelines over satellite links. The design constraint was extreme: unreliable networks, limited bandwidth, and devices with minimal processing power. That heritage still defines the protocol today.
MQTT uses a publish-subscribe model with a central broker. Devices publish messages to named topics (e.g., plant/line-1/saw-04/temperature). Other systems subscribe to topics they care about. The broker handles all routing — publishers and subscribers never communicate directly.
This decoupling is powerful. A PLC publishing its cycle count does not need to know whether one system or fifty systems are consuming that data. You can add new subscribers (a historian, an OEE calculator, a maintenance alert system) without touching the publisher configuration.
Raw MQTT has no opinion about payload structure or topic naming. For industrial use, the Sparkplug B specification (now an Eclipse Foundation standard) adds what manufacturing needs: a defined topic namespace (spBv1.0/groupId/NBIRTH/nodeId), birth/death certificates for device lifecycle management, metric definitions with datatypes and timestamps, and state management for store-and-forward during network outages.
Sparkplug B transforms MQTT from a generic messaging protocol into a purpose-built industrial data infrastructure — while keeping the lightweight transport underneath.
OPC-UA (Open Platform Communications Unified Architecture) was released by the OPC Foundation in 2008 as the successor to OPC Classic (which was COM/DCOM-based and Windows-only). It was designed to be the universal interoperability standard for industrial automation.
OPC-UA primarily uses a client-server model. An OPC-UA server exposes an address space — a hierarchical tree of nodes representing variables, objects, methods, and data types. Clients browse this address space, read values, write commands, subscribe to changes, and call methods.
The OPC-UA specification also includes a newer pub-sub extension (Part 14) that allows broker-based communication similar to MQTT. However, adoption of OPC-UA Pub/Sub remains limited compared to the client-server model.
OPC-UA's comprehensiveness comes at a cost. The full specification spans 14+ parts and thousands of pages. Standing up an OPC-UA server with a proper information model requires significant engineering effort. Client implementations must handle session management, subscription lifecycles, secure channel negotiation, and certificate management. For resource-constrained edge devices, this overhead can be prohibitive.
| Feature | MQTT | OPC-UA |
|---|---|---|
| Bandwidth | Very low (2-byte fixed header) | Higher (XML or binary encoding with rich metadata) |
| Latency | Sub-millisecond publish | Low milliseconds (session + subscription overhead) |
| Cloud Native | Yes — AWS IoT Core, Azure IoT Hub, GCP natively | Limited — requires gateways or protocol translation |
| Scalability | Millions of concurrent connections per broker cluster | Hundreds of sessions per server (practical limit) |
| Information Model | None built-in; Sparkplug B adds standardized semantics | Rich built-in address space with types, methods, events |
| Security | TLS encryption + username/password or certificate auth | X.509 certificates + message signing + encryption |
| Implementation Complexity | Simple — connect, subscribe, publish in <20 lines | Complex — sessions, channels, certificates, address space |
| Edge Device Support | Runs on microcontrollers (ESP32, Arduino) | Requires more CPU/RAM (embedded Linux minimum) |
MQTT is the stronger choice when your architecture prioritizes cloud connectivity, massive scale, or lightweight edge deployment. Specific scenarios where MQTT excels:
OPC-UA is the stronger choice when you need rich information modeling, machine-level interoperability, or integration with existing OPC infrastructure. Specific scenarios:
Yes — and many plants do. The most common hybrid pattern looks like this:
This architecture gives you the best of both worlds: OPC-UA's rich modeling and method calls for shop-floor interoperability, and MQTT's lightweight transport and native cloud connectivity for everything above the edge. The gateway translates between the two, typically running on an industrial PC or edge server.
The trade-off is added complexity: you now have two protocol stacks to maintain, and the gateway becomes a potential single point of failure. For greenfield projects, starting with MQTT end-to-end (PLC to cloud) eliminates this translation layer entirely.
PulseMQ is built on MQTT with Sparkplug B from the ground up. Our architecture connects PLCs directly to AWS IoT Core over MQTT — no OPC-UA servers, no gateways, no middleware. This gives us sub-second data from the machine to the cloud dashboard with minimal infrastructure to maintain. Sparkplug B provides the industrial semantics (birth/death certificates, metric definitions, state management) that raw MQTT lacks, while keeping the protocol lightweight enough to run on any PLC with an Ethernet port.
For a deeper look at how we use MQTT and why we believe it is the right transport for modern manufacturing, see our Why MQTT page.
See how PulseMQ uses MQTT + Sparkplug B to deliver real-time OEE, job tracking, and material traceability — without middleware.
Request a Demo