OPC-UA and MQTT are two of the most important protocols in Industrial IoT. Both enable data communication between devices, systems, and platforms, but they take fundamentally different approaches. Understanding their characteristics helps architects choose the right protocol—or combination—for specific use cases.

Protocol Fundamentals

OPC-UA (Unified Architecture) is a comprehensive industrial communication standard developed by the OPC Foundation. It provides not just data transport, but also information modeling, security, and discovery capabilities. OPC-UA is designed specifically for industrial automation and inherits decades of OPC experience in that domain.

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol originally designed for remote telemetry. It focuses on efficient data transport with minimal overhead, making it ideal for constrained devices and networks. MQTT has been widely adopted for IoT applications across industries.

Architecture Comparison

OPC-UA architecture: Client-server and publish-subscribe models. Servers expose address spaces containing nodes representing data, methods, and events. Clients browse, read, write, and subscribe to information. Complex data types, hierarchies, and relationships can be modeled directly in the protocol.

MQTT architecture: Publish-subscribe model with a central broker. Publishers send messages to topics; subscribers receive messages from topics they've subscribed to. The broker handles routing, persistence, and quality of service. Data semantics are defined by the application—MQTT provides transport only.

The key architectural difference: OPC-UA defines both transport and semantics; MQTT defines transport and leaves semantics to the application or companion specifications like Sparkplug.

Information Modeling

OPC-UA's information model is its defining strength. The protocol defines how to represent:

  • Data types with full fidelity (not just strings and numbers)
  • Object hierarchies and relationships
  • Methods that can be called remotely
  • Events and alarms with standardized structures
  • Historical data access

Industry companion specifications (PackML, PLCopen, ISA-95) define standard models for specific domains. An OPC-UA client can discover a server's capabilities, browse available data, and understand its meaning without prior knowledge of the specific implementation.

MQTT carries payload data without defining its structure. Applications must agree on data formats externally. Common approaches include:

  • JSON payloads with application-defined schemas
  • Protobuf or other binary encodings
  • Sparkplug specification providing standardized payloads

This flexibility is both strength and weakness—MQTT adapts to any data format, but interoperability requires additional standardization effort.

Security Comparison

OPC-UA includes comprehensive built-in security:

  • Authentication via certificates, usernames/passwords, or tokens
  • Encryption using AES for message security
  • Integrity protection using RSA signatures
  • Security policies defining allowed cryptographic algorithms
  • Audit logging capabilities

Security is integral to the specification—every OPC-UA implementation supports the same security mechanisms. The downside is complexity; certificate management in industrial environments can be challenging.

MQTT delegates security to the transport layer:

  • TLS for encryption and server authentication
  • Username/password authentication to the broker
  • Optional client certificates
  • Access control lists at the broker

This approach is simpler but requires proper configuration. MQTT 5.0 adds enhanced authentication options, but security still depends more on implementation than specification.

Performance Characteristics

MQTT advantages:

  • Minimal protocol overhead (2-byte minimum header)
  • Efficient for small, frequent messages
  • Low memory footprint suitable for constrained devices
  • Simple to implement; runs on microcontrollers

OPC-UA considerations:

  • More protocol overhead for full information modeling
  • Binary encoding (UA Binary) more efficient than JSON/XML
  • Subscription-based data changes reduce polling overhead
  • Full implementations require more resources

For raw throughput with minimal overhead, MQTT wins. For rich data modeling with maintained semantics, OPC-UA's overhead provides value. OPC-UA pub/sub mode (relatively new) approaches MQTT efficiency while retaining information modeling.

Scalability Patterns

MQTT scales horizontally through broker clustering. Large deployments use broker clusters that can handle millions of connections. Topic-based routing enables efficient message distribution. Cloud MQTT services provide virtually unlimited scale.

OPC-UA traditionally scales through aggregation servers that consolidate multiple data sources. The newer pub/sub model enables more distributed architectures. Large-scale OPC-UA deployments typically use hierarchical structures with aggregation at each level.

Both protocols can handle enterprise-scale deployments, but with different architectural patterns. MQTT's simpler model often makes horizontal scaling more straightforward; OPC-UA's rich modeling makes aggregation more meaningful.

Implementation Ecosystem

OPC-UA has broad industrial support:

  • Most PLCs and industrial controllers include OPC-UA servers
  • SCADA systems, historians, and MES typically support OPC-UA
  • Certified implementations ensure interoperability
  • Companion specifications for specific industries

MQTT has broad IoT support:

  • Every major cloud platform supports MQTT
  • Libraries available for every programming language
  • Implementations for even the smallest microcontrollers
  • Large open-source ecosystem

If you're connecting to industrial equipment, OPC-UA is probably available. If you're connecting to cloud platforms or IoT services, MQTT is universal.

Use Case Comparison

OPC-UA excels for:

  • Plant floor integration between PLCs, SCADA, and MES
  • Complex data that benefits from standardized modeling
  • Applications requiring method calls and not just data
  • Regulatory environments requiring audit capabilities
  • Brownfield integration with existing industrial equipment

MQTT excels for:

  • Edge-to-cloud data transmission
  • Large-scale sensor networks with simple data
  • Constrained devices with limited resources
  • Applications prioritizing simplicity over semantics
  • Greenfield IoT deployments without legacy constraints

The Combined Approach

Many architectures use both protocols in complementary roles:

OPC-UA at the plant floor: Connect to PLCs, DCS, and SCADA systems. Leverage existing industrial OPC-UA infrastructure. Benefit from standardized information models for manufacturing.

MQTT for cloud connectivity: Gateway converts OPC-UA data to MQTT for cloud transmission. Leverage MQTT's simplicity and cloud platform support. Benefit from broker-based scaling and message routing.

This pattern provides industrial-grade connectivity within the plant and efficient cloud integration beyond it. Gateways bridge the protocols, translating OPC-UA's rich information model to MQTT payloads (often using Sparkplug for consistency).

OPC-UA over MQTT

The OPC Foundation has specified OPC-UA pub/sub over MQTT transport, combining both protocols' strengths. OPC-UA information modeling and security ride on MQTT's efficient transport and broker infrastructure.

This approach provides:

  • OPC-UA's standardized data modeling
  • MQTT's efficient transport and broker scaling
  • Cloud platform compatibility via MQTT
  • Maintained semantics end-to-end

Implementations are still maturing, but this represents a potentially powerful combination for future architectures.

Making the Choice

Choose OPC-UA when:

  • Connecting to industrial equipment that already supports it
  • Data semantics and modeling are critical
  • You need method invocation, not just data
  • Industry-standard models (PackML, ISA-95) apply
  • Compliance requires comprehensive security and audit

Choose MQTT when:

  • Connecting to cloud platforms and services
  • Devices have constrained resources
  • Simplicity is valued over semantic richness
  • You control both ends and can define your own semantics
  • Scale and efficiency are paramount

Often, the answer is both—leveraging each protocol's strengths in different parts of the architecture. The protocols complement more than compete.