Choose OPC UA when the collector needs to discover and read a structured industrial source. Choose MQTT when producers need to publish messages through a broker to one or more consumers. Use both when the plant-facing interface and the upstream distribution problem are different.
That rule is only a starting point. OPC UA is a family of specifications that includes Client/Server services, information modeling, Alarms and Conditions, Historical Access, and PubSub. MQTT is a lightweight publish/subscribe messaging protocol. Comparing a typical OPC UA Client/Server connection with an MQTT broker architecture is useful, but the two names do not describe equivalent layers.
The practical differences
| Decision area | Typical OPC UA Client/Server use | Typical MQTT use |
|---|---|---|
| Connection pattern | Client connects to a server endpoint, browses, reads, calls methods, or creates subscriptions | Publishers and subscribers connect to a broker and exchange messages through topics |
| Source context | Address space can expose typed nodes, relationships, metadata, methods, and domain models | Topic and payload meaning comes from the application’s agreed schema and conventions |
| Distribution | Each client has its own session, subscriptions, and monitored items | Broker decouples producers from consumers and supports fan-out |
| Infrastructure | Requires an OPC UA server and compatible clients | Requires an MQTT broker plus publisher and subscriber applications |
| Common fit | Plant equipment, PLC gateways, SCADA, and industrial software that already expose OPC UA | Remote telemetry, edge-to-central messaging, and data shared with several consumers |
Actual products can support only part of either standard. Check profiles, protocol versions, authentication methods, data models, queue behavior, and limits before choosing an architecture.
OPC UA carries an industrial information model
An OPC UA server can organize measurements under equipment objects, attach engineering units and ranges, expose status and timestamps, define methods, and use companion specifications for industry-specific models. A client can browse that address space and select nodes without requiring every meaning to be encoded in a topic string.
This is valuable when the source system already provides context that the collector should preserve. For example, a plant collector may browse a packaging-line server, identify each motor’s speed and running state, and subscribe to those variables. The choice between reads and monitored-item subscriptions is covered in the OPC UA polling versus subscription guide.
OPC UA does not guarantee that every server has a rich or consistent model. Some expose flat tag lists, incomplete metadata, or vendor-specific structures. Security also depends on endpoint configuration, certificate trust, user identity, and authorization. The presence of OPC UA does not make a deployment secure by itself.
MQTT moves application messages through topics
MQTT clients publish messages to topic names. The broker routes them to matching subscribers. A device or edge application chooses the topic structure and payload, which might be JSON, binary data, or another agreed format.
Core MQTT does not define an OPC UA-style equipment address space or industrial semantic model. Teams need a schema, naming convention, units policy, timestamp fields, and versioning rules if downstream consumers require consistent meaning. This extra design work can be reasonable when the publisher already knows exactly what telemetry it must send.
The broker pattern works well for distributed sites. A site gateway can publish selected telemetry upstream without allowing every central consumer to connect to each plant source. Multiple authorized applications can subscribe without adding a separate OPC UA session to the source for each consumer.
MQTT does not require an Internet connection. A broker can run on premises, at an edge site, in a data center, or in a cloud environment. Routing and security policy determine who can reach it.
Delivery settings do not create a historian
MQTT Quality of Service describes message delivery between one sender and one receiver in a protocol flow:
- QoS 0 is at most once.
- QoS 1 is at least once and can produce duplicates.
- QoS 2 is exactly once for that delivery flow.
These levels do not guarantee that an application wrote a unique, durable historian record. The publisher, broker, subscriber, mapping logic, and database can each fail outside that flow.
A retained MQTT message is the broker’s stored current message for a topic, delivered to future matching subscribers. It is not a time series. Persistent sessions can preserve subscriptions and pending QoS 1 or QoS 2 messages within configured session expiry and broker resource limits. They are not the same as end-to-end historical backfill.
OPC UA Client/Server subscriptions also use queues and retransmission mechanisms. Durable Subscriptions and Historical Access exist, but support is implementation-dependent. Neither protocol can recover values that the source or edge application never captured.
For either choice, define outage boundaries. Test a device disconnect, edge restart, broker or server restart, network partition, subscriber outage, queue overflow, and storage failure. Record where data is buffered, when it expires, how duplicates are identified, and how gaps appear.
Security depends on the deployment
OPC UA can use application certificates, signed or encrypted SecureChannels, and user authentication. MQTT deployments can use TLS, client certificates or credentials, and broker access-control lists. Both can also be deployed with weak settings.
Review the complete path: certificate lifecycle, credential storage, topic or node permissions, firewall rules, software updates, logging, and incident isolation. Encryption protects data in transit but does not correct an overprivileged account or a compromised endpoint.
When to choose OPC UA, MQTT, or both
OPC UA is a reasonable default when the source already exposes an OPC UA server and the application needs browsing, source metadata, equipment relationships, alarms, or methods. It keeps the collector close to the source’s industrial model.
MQTT is a reasonable default when devices or gateways publish a defined telemetry payload, a broker is part of the managed architecture, and several consumers need decoupled access. It also suits constrained or intermittent links when the selected clients and broker have tested queue and session behavior.
Using both can separate collection from distribution. An edge component may act as an OPC UA client inside the plant, select and normalize source data, then publish an approved payload to an MQTT broker for upstream consumers. That bridge must define timestamp, quality, identity, units, retry, and duplicate behavior. The existence of both protocols does not supply those rules automatically.
OPC UA PubSub can also use MQTT as a transport mapping. That is not the same as publishing an arbitrary JSON payload from a custom gateway. Confirm that the publishers and subscribers support the same OPC UA PubSub profiles, encoding, security, and information model.
TDengine collection paths
TDengine TSDB Enterprise documents separate ingestion connectors for OPC UA and MQTT. OPC UA tasks collect points or Alarms and Events from a server. MQTT tasks subscribe to broker topics, parse message payloads, and map fields into TDengine tables. The current TDengine MQTT ingestion guide documents broker connection, supported protocol versions, topic QoS, TLS options, and payload mapping.
These connectors provide two source paths into TDengine TSDB. The documentation does not state that they translate OPC UA traffic into MQTT or make the two protocols interoperable. If an architecture uses both, define and operate the bridge separately unless a documented component explicitly provides it.
