FoundryNet / Compare / Modbus TCP vs MQTT / Sparkplug B
Protocol comparison

Modbus TCP vs MQTT / Sparkplug B

The question behind every gateway purchase: should the device be polled, or should it publish?

Get an API key All 14 adapters

Side by side

The comparison

Modbus TCPMQTT / Sparkplug B
SpecificationModicon Modbus, TCP encapsulation (Modbus-TCP)OASIS MQTT 3.1.1 / 5.0, Eclipse Sparkplug B
First published1979 (serial), 1999 (TCP)1999 (MQTT), 2016 (Sparkplug B)
TransportTCP, port 502TCP 1883, TLS 8883, via a broker
Data modelFlat 16-bit registers and single-bit coils. No types, no names, no metadata — a register is a number at an address.MQTT itself carries opaque bytes on a topic. Sparkplug B adds a protobuf payload, a topic namespace, and birth/death certificates so state is knowable.
DiscoveryNone. You need the vendor's register map, usually a PDF.Sparkplug B birth certificates announce metrics on connect. Plain MQTT: none.
SecurityNone in the base specification. Whatever the network gives you.TLS plus broker-level authentication and topic ACLs.
Polling or subscriptionPolling only. The client asks; the device answers.Publish/subscribe, report-by-exception. The device pushes when a value changes.
Implementation complexityLowest of any protocol here. A working client is ~200 lines.Low to implement, moderate to operate — the broker becomes infrastructure you own.
Typical industriesEverything. Drives, meters, inverters, sensors, PLCs, BESS.IIoT gateways, distributed and remote assets, energy, anything behind a cellular link.
Forge supportAdapter shipped. 14 OEM families mapped.Adapter shipped. 9 OEM families mapped.

Where each one wins

Modbus TCP

Strength. Universal, trivial to implement, works on hardware from 1985.

What it costs you. Carries no semantics whatsoever. Scaling, byte order and register meaning all live outside the protocol.

Modbus TCP adapter →

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 →

Polling is a choice you make once and pay for continuously; publish/subscribe is a choice you make once and operate forever. Modbus over a LAN with a hundred devices is fine. Modbus over a cellular link to a hundred remote sites is a bandwidth bill and a latency problem, and that is where Sparkplug B earns its keep.


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.

Modbus TCP — Haas

# raw tag on the wire
{"parts_counter": 1450}
# normalized
{"part_count": 1450}

MQTT / Sparkplug B — Trumpf

# raw tag on the wire
{"part_ct": 1450}
# normalized
{"part_count": 1450}

Same field: part_count. 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.