MQTT, OPC-UA or Modbus? Choosing the wire for industrial IoT

Teams often frame this as a contest. It is not. Modbus, OPC-UA and MQTT solve different problems at different layers of a plant, and most real deployments use at least two of them. The mistake is not picking the wrong one; it is forcing a single protocol to do a job it was never designed for.

Modbus: the machine's native language

Modbus is thirty-year-old, register-based and utterly unsophisticated, which is exactly why almost every PLC, drive and meter on a factory floor speaks it. It has no security, no data model and no discovery. Use it where it already exists: to read from equipment. Do not use it beyond the cell; it was never meant to cross a network boundary.

OPC-UA: the structured, secure plant model

OPC-UA gives you typed, browsable data with built-in authentication and encryption. It is the right choice when you need a rich model of the plant (hierarchies of equipment, alarms with semantics, historical access) and when you are integrating with SCADA or MES systems that already speak it. Its cost is complexity and heavier stacks; it is not what you want on a battery-powered sensor or across an unreliable cellular link.

MQTT: the transport to the cloud

MQTT is a lightweight publish-subscribe transport built for unreliable networks. It carries small messages efficiently, handles intermittent connectivity gracefully and scales to millions of clients. It has no data model of its own, which is a feature, as long as you impose one. Sparkplug B is the convention we use to give MQTT topics and payloads consistent structure in industrial contexts.

The pattern that usually wins

• Modbus (or a vendor protocol) between equipment and an edge gateway, inside the cell.
• OPC-UA between the gateway and plant systems that need a rich model, when those systems exist.
• MQTT with Sparkplug B from the gateway to the cloud, buffered locally so nothing is lost when the link drops.

The gateway is where the translation happens, and it is where most of the engineering effort goes: normalizing units, handling timestamps, buffering, security. Get the gateway right and the protocol choices around it become straightforward.

Questions we ask before deciding

• What does the equipment already speak? You rarely get to change it.
• Who else needs the data on site: SCADA, MES, historians?
• How reliable and how expensive is the link to the cloud?
• What is the power budget of the device sending data?
• Who is responsible for security at each hop?

Answer those honestly and the diagram draws itself. Skip them and you will spend the project fighting a protocol instead of building the product.