Insights · IIoT

MQTT vs OPC UA, without the protocol wars.

Both protocols solve real industrial problems — just not the same ones. A pragmatic look at where MQTT and OPC UA each earn their place in a modern IIoT stack, drawn from Cyntech deployments on petrochemical, energy and utilities sites.

← All insightsPublished 15 Jun 2026 · 7 min read

The MQTT vs OPC UA question comes up in almost every IIoT workshop we run. The honest answer is that most mature stacks use both: OPC UA close to the process for structured, self-describing reads, and MQTT (usually with Sparkplug B) as the north-bound event bus feeding the unified namespace, historians and cloud analytics.

MQTT in one paragraph

A lightweight pub/sub protocol with a broker in the middle. Producers publish to topics, consumers subscribe, and neither needs to know the other exists. Combined with Sparkplug B it adds birth/death certificates, state, and a canonical topic namespace for industrial devices.

OPC UA in one paragraph

A client/server (and now pub/sub) protocol with a rich, browsable information model. Companion Specifications describe pumps, drives, robots, weighers and more in a vendor-neutral way — the address space itself carries semantic meaning, not just values.

Side-by-side comparison

AttributeMQTTOPC UA
ModelPub/sub via a broker — decoupled producers and consumers.Client/server (with optional pub/sub) — structured address space.
PayloadOpaque; teams standardise via Sparkplug B or JSON contracts.Rich, self-describing information model with Companion Specs.
TransportTCP + TLS; MQTT-SN over UDP for constrained links.OPC UA TCP or HTTPS; UDP multicast for pub/sub.
DiscoveryTopic-based; birth/death certs with Sparkplug B.Native browse + GDS for global discovery and cert management.
SecurityTLS + per-device certs; broker ACLs; app-layer encryption optional.Built-in signing/encryption, user tokens, role-based access.
FootprintTiny — runs on microcontrollers and edge gateways.Heavier stack; nano/micro profiles exist but rarely trivial.
ToolingHiveMQ, EMQX, Mosquitto; MQTT Explorer for debugging.UAExpert, Prosys OPC UA Browser; vendor SDKs (open62541, Milo).
Best fitMany small publishers, cloud/edge fan-out, event-driven UNS.Deterministic control-adjacent reads, rich models, ISA-95 mapping.

When MQTT wins

  • Fan-out from hundreds of edge devices into a UNS, historian and cloud.
  • Intermittent links — cellular RTUs, satellite, marine, mining vehicles.
  • Event-driven architectures where consumers come and go independently.
  • Petrochemical sites where you need store-and-forward semantics with birth/death.

When OPC UA wins

  • Structured reads directly off PLCs, drives and DCS with rich context.
  • Vendor-neutral integration where Companion Specs cover the equipment class.
  • Deterministic sampling and browse-based tag discovery during commissioning.
  • Sites already invested in OPC UA GDS for certificate lifecycle management.

Common anti-patterns

  • Publishing raw, unlabelled JSON over MQTT and calling it a UNS.
  • Exposing an OPC UA server directly to the internet without a DMZ.
  • Using MQTT QoS 0 for anything you plan to bill or report on.
  • Trying to control from cloud over MQTT with second-plus round-trip latency.
Our default recipe

OPC UA at the edge, MQTT to the world.

Terminate OPC UA at an edge gateway close to the PLCs, transform into a Sparkplug B topic tree, and publish north-bound over MQTT with mTLS. This gives you rich semantics where they matter and light, resilient distribution everywhere else.

Talk to our IIoT team

Related reading

Let's build

Have a project in mind? Let's scope it together.

Tell us about your site, your constraints and your timeline. We'll respond with a practical engineering perspective — not a sales pitch.

View projects