FoundryNet / Compare / MQTT / Sparkplug B vs OPC UA
Protocol comparison

MQTT / Sparkplug B vs OPC UA

The architecture question for a greenfield IIoT build: broker in the middle, or client-server to each asset?

Get an API key All 14 adapters

Side by side

The comparison

MQTT / Sparkplug BOPC UA
SpecificationOASIS MQTT 3.1.1 / 5.0, Eclipse Sparkplug BIEC 62541
First published1999 (MQTT), 2016 (Sparkplug B)2008
TransportTCP 1883, TLS 8883, via a brokerTCP binary on 4840, or HTTPS
Data modelMQTT itself carries opaque bytes on a topic. Sparkplug B adds a protobuf payload, a topic namespace, and birth/death certificates so state is knowable.A full information model: typed nodes, references, objects, methods and historical access. The richest model in industrial automation.
DiscoverySparkplug B birth certificates announce metrics on connect. Plain MQTT: none.Built in. Browse the address space, read the type definitions.
SecurityTLS plus broker-level authentication and topic ACLs.Built in and mandatory to configure: X.509 certificates, signing, encryption, user authentication.
Polling or subscriptionPublish/subscribe, report-by-exception. The device pushes when a value changes.Both. Polled reads and subscriptions with monitored items and dead-banding.
Implementation complexityLow to implement, moderate to operate — the broker becomes infrastructure you own.High. The stack is large, certificate handling is a real operational task, and server implementations vary.
Typical industriesIIoT gateways, distributed and remote assets, energy, anything behind a cellular link.Modern machine tools, robotics, packaging, anything specified after ~2015.
Forge supportAdapter shipped. 9 OEM families mapped.Adapter shipped. 23 OEM families mapped.

Where each one wins

MQTT / Sparkplug B

Strength. Report-by-exception over an expensive or unreliable link. One broker fans out to many consumers.

What it costs you. Plain MQTT has no schema at all — the payload is whatever the publisher decided that day.

MQTT / Sparkplug B adapter →

OPC UA

Strength. Self-describing. You can walk a server you have never seen and learn what it holds.

What it costs you. Self-describing is not the same as standardised — two vendors model the same machine differently, so the names still need mapping.

OPC UA adapter →

OPC UA models the asset; MQTT moves the message. They compose better than they compete — OPC UA PubSub over MQTT exists precisely because the industry stopped treating this as an either/or. If you are choosing under pressure: OPC UA when you need to *interrogate* equipment, MQTT when you need to *ship* readings cheaply.


The Forge angle

Whichever one you pick, the output is the same

Forge is not an argument for a protocol. It is the layer that makes the choice stop mattering downstream: 16,908 curated mappings across 14 protocol adapters, resolving to 366 canonical fields with enforced units and physics bounds.

Two devices, two protocols, two vendors, two entirely different tag names — and one canonical field out. Both of these are real mappings from the corpus, not illustrations.

MQTT / Sparkplug B — MiR (Mobile Industrial Robots)

# raw tag on the wire
{"/robot_status/battery_percentage": 1450}
# normalized
{"amr.battery.charge": 1450}

OPC UA — AGILOX

# raw tag on the wire
{"battery_pct": 1450}
# normalized
{"amr.battery.charge": 1450}

Same field: amr.battery.charge. Same unit contract, same physics bounds, same shape. Your query does not need to know which protocol the reading arrived on.

# Try it against both, with no key and no account
docker run -p 8000:8000 ghcr.io/foundrynet/forge-sandbox

Keep reading

The protocol you pick matters less than the schema underneath. The Machine Agent, weekly. Read it →
Get the thesis behind this infrastructure — The Machine Agent, weekly.