MQTT vs Modbus TCP, when to use which (and when to bridge)
A field guide to picking between MQTT and Modbus TCP for industrial and connected-product fleets, with a decision tree based on fleet size, regulatory posture, and whether you are retrofitting or building greenfield.
Search "mqtt vs modbus tcp" and the first ten results all conclude the same way: "use both." Which is technically correct and operationally useless. By the time a hardware founder is Googling that query, they are not asking a philosophy question. They are sitting in front of a PLC and a cloud account, wondering which side of the fence they should put their integration code on.
This is the post we wish existed when we were doing this for the first time. Modbus TCP is the protocol your factory floor already speaks. MQTT is the protocol your cloud expects. Picking one without bridging is faster to ship and cheaper to maintain. Bridging is sometimes the only honest answer. Here is how to tell which case you are in.
The two protocols, in two paragraphs
Modbus TCP is a 1999 wire framing of a 1979 industrial register protocol. It assumes a single short-lived TCP connection between a master and one slave per session, polling integer registers at fixed addresses. There is no broker, no topic tree, no QoS. Reliability comes from the master polling on a tight loop and detecting timeouts. Security comes from a VLAN. The slave is dumb on purpose.
MQTT is a 1999 publish-subscribe protocol designed for satellite-uplink telemetry from oil rigs, where the network is unreliable and the device might disappear for an hour. Devices connect to a broker, publish to topics, and subscribe to topics they care about. The broker handles fan-out, retained messages, will messages, QoS levels, and TLS. Devices stay connected for hours or days at a time.
These were designed for different problems. Most of the confusion in the comparison space comes from people benchmarking them as if they were the same kind of object.
Side-by-side, when the marketing material gets out of the way
| Dimension | Modbus TCP | MQTT |
|---|---|---|
| Year and origin | 1999, factory floor PLCs | 1999, telemetry over flaky links |
| Topology | Point to point, master polls slaves | Many to many through a broker |
| Connection model | Short, per-transaction | Long-lived, hours to days |
| Data shape | Fixed-address integer registers | Arbitrary topic plus payload |
| Discovery | None, you read the manual | None at the protocol level (Sparkplug B adds it) |
| QoS | None, polling rate is your QoS | 0, 1, 2, plus retained, plus LWT |
| Security | Originally none, TLS as an add-on | TLS first-class, ACLs at the broker |
| Typical latency | 5 to 50 ms LAN | 50 to 300 ms over WAN |
| Typical throughput | A few hundred polls per second per slave | Tens of thousands of messages per second through one broker |
| Failure mode | Half-open sockets, register drift | Dropped subscriptions, retained-message rot |
| Tooling | Modscan, Modpoll, pymodbus, libmodbus | mqttx, mosquitto-pub, paho, EMQX, HiveMQ |
| Cost to operate | Free, runs on the PLC | Free protocol, broker is hosted or self-run |
Both protocols are cheap. The cost is somewhere else.
The three axes that actually decide it
We have shipped enough of these now to flatten the question to three axes. Score yourself honestly, then read the verdict at the bottom.
Axis 1: Are you building greenfield or retrofitting?
Greenfield means you control the device firmware, the network, and the cloud. Retrofit means there is already a PLC, an HVAC unit, a power meter, or a medical chamber on site, it speaks Modbus because that is what came on the data sheet, and you are not allowed to flash it.
If you are retrofitting, Modbus TCP is the floor protocol whether you like it or not. The choice is not "MQTT or Modbus", it is "how do I get this Modbus data somewhere useful." The honest answer there is bridging, which we cover separately in the Modbus to MQTT production guide.
If you are greenfield and you control the device firmware, MQTT is almost always the right answer at the device-to-cloud edge. The reason is not technical, it is economic: MQTT brokers, dashboards, alerting tools, and SDKs outnumber Modbus equivalents by an order of magnitude, and the people who maintain them work in your timezone.
Axis 2: How big is the fleet, and what is the topology?
Modbus TCP scales horizontally by adding masters. Each master polls a small group of slaves on a local network. The protocol does not have a concept of "the fleet". A central system that wants visibility across 50 sites needs to either run 50 masters and aggregate, or talk to one master per site that aggregates locally. The data plane does not help you, you build the federation yourself.
MQTT scales vertically through the broker. One broker can hold connections to tens of thousands of devices and route messages between them with topic-tree authorization. The broker becomes a load-bearing piece of infrastructure: when it goes down, the whole fleet goes dark. You design around that with broker clusters, persistent sessions, and shared subscriptions.
Below 10 devices on a single LAN, Modbus is operationally simpler. Above 1000 devices across multiple sites, MQTT (or something MQTT-shaped) is the only thing that holds together. The middle ground (10 to 1000 devices, mixed topology) is where bridging starts to earn its keep.
Axis 3: What is your regulatory posture?
If you are shipping into a regulated industry (medical, energy grid, food, automotive ECUs), the question is not "which protocol is faster" but "which protocol leaves an audit trail my auditor will accept." MQTT brokers can produce structured access logs, retained-message snapshots, and per-topic ACLs that map cleanly to a regulatory ask. Modbus TCP traffic is invisible to anyone not packet-capturing the wire, and the protocol does not authenticate the master at all.
For Corvita Biomedical, who run our gateways in front of neonatal medical devices, every register read is also an audit event. We chose MQTT over TLS as the upstream transport partly because the broker access log doubles as the SOC 2 evidence trail. Modbus stays on the LAN, between the device and the gateway, where it belongs.
Greenfield, regulated, fleet over 100: MQTT, no contest. Retrofit, light regulation, fleet under 50: Modbus end to end, no bridge. Anything in between: bridge, and accept the cost of running a translation layer.
When you should not bridge
There are three cases where bridging Modbus to MQTT is a mistake:
- The device already speaks MQTT. If you have any influence over the firmware, write to MQTT directly. Bridging adds a hop, a cache, and a translation step that you will spend the next two years debugging. We have seen this pattern in newer industrial sensors that ship with both protocols, and the customer ships with Modbus because that is what the integrator knew. Six months later they are paying us to undo it.
- Latency under 10 ms matters. Closed-loop control on a factory floor is Modbus on a dedicated VLAN. Adding a broker, even a co-located one, will eat your timing budget.
- The auditor wants a single immutable log. If your regulator wants every device read in one place with a tamper-evident trail, you do not want two protocols' logs to reconcile. Pick MQTT and put the gateway in front of the Modbus device, but reflect every Modbus read as an MQTT message. Then your immutable log is one stream.
When you should bridge
You should bridge when the device speaks Modbus, you cannot change that, and you need MQTT-shaped data downstream because the rest of your stack expects it. This is the dominant case in industrial retrofit. Doing it well is harder than the tutorials make it look. The seven failure modes are documented in detail in our Modbus TCP to MQTT production guide.
How SCADABLE thinks about it
The reason we built SCADABLE the way we did is that for most hardware companies the answer is not one or the other, it is "give me a single API and figure out which one is on the wire." Our SDK lets you describe the device once in Python (registers, units, scaling, polling rate). The compiler emits a YAML driver that the gateway runs natively, whether the upstream link is MQTT, Modbus, OPC-UA, BLE, or HTTP. From your application's perspective the device is the device, not the protocol.
If you are still in the "should I pick MQTT or Modbus" stage, this post is doing its job. If you have decided to bridge, the production guide is next. If you have decided neither and you want one library across all of them, let us talk.