MQTT is the lightweight messaging protocol that has quietly become the backbone of industrial IoT, and the broker is the piece that makes it work. Instead of every device talking directly to every consumer, everything connects to a central broker that routes messages. This guide explains what an MQTT broker is, how publish/subscribe works, and why brokers matter for cloud-native SCADA in oil and gas.
What Is an MQTT Broker? in one line: An MQTT broker is a server that receives messages published to named topics and forwards them to the clients that subscribed to those topics. It is the central hub in MQTT's publish/subscribe model, decoupling data sources from data consumers so devices never talk to each other directly.
MQTT uses a publish/subscribe pattern rather than the request/response polling that older SCADA protocols rely on. A publisher - say an RTU or edge gateway at a wellsite - opens one persistent TCP connection to the broker and publishes readings to a topic such as permian/pad12/well3/tubing_pressure. Any number of consumers (a cloud SCADA, a historian, an analytics service) subscribe to that topic and the broker pushes each new message to all of them. The publisher and subscribers never know about each other; the broker is the only thing either side connects to.
That decoupling is the point. New consumers can be added without touching field devices, and a field device only needs a single outbound connection - which matters enormously on cellular or satellite links behind carrier-grade NAT, where inbound polling is impractical. The broker also handles retained messages (the last known value on a topic) and a last will and testament message that the broker publishes automatically if a device drops offline unexpectedly.
MQTT defines three quality-of-service levels the broker enforces per message: QoS 0 (at most once, fire and forget), QoS 1 (at least once, may duplicate), and QoS 2 (exactly once, with a four-part handshake). For telemetry over marginal links, QoS 1 is the usual choice - delivery is guaranteed even if a duplicate slips through, and the overhead is modest.
Raw MQTT only moves opaque payloads on arbitrary topics, so industry adopted Sparkplug B, a specification that standardizes topic structure, payload encoding (Google Protocol Buffers), state management, and how a device reports its full tag set on connect. Sparkplug B turns a generic broker into something a SCADA platform can auto-discover and model, and it is the basis of most unified namespace designs. When operators say 'MQTT SCADA,' they almost always mean MQTT with Sparkplug B running through a broker.
In a cloud SCADA architecture the broker is the meeting point between the field and the platform. Edge gateways at each site publish to the broker; the cloud SCADA subscribes and ingests. Because the connection is outbound and encrypted (MQTT over TLS on port 8883), no inbound firewall ports need to be opened at the wellsite - a major security advantage over polling protocols exposed to the internet.
Brokers can be self-hosted (open-source options like Mosquitto and EMQX, or commercial ones), run at the edge, or provided as a managed cloud service. Merobix ingests MQTT and Sparkplug B alongside Modbus, DNP3, and OPC UA, so an operator standardizing on a broker-based unified namespace can flow the same data into a cloud SCADA without abandoning the polled devices they already run.
It receives every message a client publishes to a topic and forwards a copy to every client subscribed to that topic. It handles quality-of-service delivery guarantees, retained last-known values, and offline detection, so publishers and subscribers stay completely decoupled from one another.
MQTT is the messaging protocol - the rules for connecting, publishing, and subscribing. The broker is the server software that implements those rules and routes messages between clients. You cannot run MQTT publish/subscribe without a broker; it is the central component.
Field devices make a single lightweight outbound connection to the broker instead of accepting inbound polls, which suits cellular and satellite links behind NAT and avoids opening firewall ports. With Sparkplug B it adds standardized modeling, offline detection, and report-by-exception efficiency that fit remote wellsites and pipelines.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.