Global – October 27, 2026 -- Industrial data architects should choose OPC UA when a collector must discover and read a structured source, and MQTT when producers publish through a broker to one or more consumers, according to a TDengine technical comparison. The guide adds that the two names do not describe equivalent layers, so the rule is only a starting point.
OPC UA preserves equipment context that MQTT leaves to the architect
OPC UA is a family of specifications covering Client/Server services, information modeling, Alarms and Conditions, Historical Access and PubSub. A server can organize measurements under equipment objects, attach engineering units and ranges, and expose status, timestamps and methods. A client can browse that address space instead of encoding meaning in topic strings.
Not every server delivers a rich model, however. Some expose flat tag lists, incomplete metadata or vendor-specific structures.
Core MQTT defines no equipment address space or industrial semantic model. Teams that need consistent downstream meaning must set a schema, naming convention, units policy, timestamp fields and versioning rules.
MQTT brokers let site gateways feed several consumers without extra source sessions
A site gateway can publish selected telemetry upstream, so central consumers do not connect to each plant source. Multiple authorized applications can subscribe without an additional OPC UA session on the source for each one. A broker can run on premises, at an edge site, in a data center or in the cloud, so MQTT does not require an Internet connection.
MQTT QoS levels 0, 1 and 2 do not create a historian
QoS 0 delivers at most once. QoS 1 delivers at least once and can produce duplicates. QoS 2 delivers exactly once within a single delivery flow. None of these guarantees a unique, durable historian record, because the publisher, broker, subscriber, mapping logic and database can each fail outside that flow.
A retained message is the broker's stored current message for a topic, not a time series. Persistent sessions preserve subscriptions and pending QoS 1 or QoS 2 messages only within session expiry and broker resource limits. OPC UA Durable Subscriptions and Historical Access exist, but support depends on the implementation. Neither protocol can recover values the source or edge application never captured.
The guide recommends testing seven failure cases for either protocol:
- device disconnect
- edge restart
- broker or server restart
- network partition
- subscriber outage
- queue overflow
- storage failure
Teams should also record where data is buffered, when it expires, how duplicates are identified and how gaps appear.
Security hinges on configuration for both protocols
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 be deployed with weak settings. Encryption protects data in transit but does not correct an overprivileged account or a compromised endpoint.
Hybrid designs need an explicitly defined bridge
An edge component can act as an OPC UA client inside the plant, normalize source data and publish an approved payload to an MQTT broker. That bridge must define timestamp, quality, identity, units, retry and duplicate behavior.
OPC UA PubSub can use MQTT as a transport mapping, but this differs from publishing arbitrary JSON from a custom gateway. Publishers and subscribers must support the same PubSub profiles, encoding, security and information model.
TDengine TSDB Enterprise ingests OPC UA and MQTT through separate connectors
OPC UA tasks collect points or Alarms and Events from a server. MQTT tasks subscribe to broker topics, parse payloads and map fields into TDengine tables. The documentation does not state that the connectors translate OPC UA traffic into MQTT or make the protocols interoperable, so any bridge must be operated separately.