If you build connected devices for a living, you have almost certainly shipped MQTT without thinking twice about where it came from. It is the quiet workhorse behind sensor networks, home automation hubs, industrial dashboards and cloud telemetry pipelines. What almost nobody remembers is that MQTT was never designed for smart homes or hobbyist boards. It was invented to keep an eye on an oil pipeline running through the middle of nowhere, and that origin story explains why it is still the default choice for IoT development today.
What is MQTT
MQTT is a lightweight publish/subscribe messaging protocol built for machines that need to exchange small messages over unreliable, low-bandwidth networks. Instead of every device talking directly to every other device, clients publish messages to named "topics" on a central broker, and other clients subscribe to the topics they care about. A temperature sensor might publish to factory/line3/temp while a dashboard, an alarm service and a logging database all subscribe to it independently. Nothing needs to know about anything else, which is exactly what you want when you are wiring up hundreds or thousands of connected devices.
The protocol is deliberately tiny. A minimal MQTT message header is just two bytes, and the whole specification is small enough to run on a microcontroller with a few kilobytes of RAM. That frugality is not an accident. It is the direct fingerprint of the problem MQTT was first built to solve.
The oil pipeline that started it all
MQTT was created in 1999 by Dr. Andy Stanford-Clark of IBM and Arlen Nipper, then at Arcom (later part of Eurotech). Their task was to monitor a long oil pipeline crossing remote terrain, feeding readings back into a SCADA industrial control system. The only practical way to reach those distant sensors was an expensive satellite link, billed by the byte and prone to dropping out.
Those constraints ruled out anything chatty or heavyweight. The engineers needed a protocol that used as few bytes as possible, tolerated flaky connections, and could pick up where it left off after a dropout without flooding the network. The answer was a publish/subscribe design with configurable quality-of-service levels and a small, predictable footprint. In other words, MQTT was shaped by scarcity, and scarcity is the natural condition of most embedded systems.
Why pipeline constraints became IoT superpowers
Fast forward two decades and the exact qualities that made MQTT good for a satellite-linked pipeline are the qualities that make it ideal for the Internet of Things. Battery-powered sensors cannot afford verbose protocols. Cellular and LoRa links have tight data budgets. Devices drop off Wi-Fi and reconnect constantly. MQTT was already designed for a world where bandwidth is precious and connections are unreliable, so it slid into the IoT era as if it had been waiting for it.
The publish/subscribe model also happens to scale beautifully. Because publishers and subscribers never talk to each other directly, you can add new consumers of the data (an analytics service, a mobile app, a machine-learning model) without touching the firmware on a single field device. For anyone building embedded products that need to grow over time, that decoupling is worth its weight in gold.
MQTT in the field today
MQTT is now an open OASIS and ISO standard, with mature brokers like Mosquitto, HiveMQ and EMQX, and it underpins large chunks of both consumer and industrial IoT. Here in the Philippines, we see it turn up constantly: agricultural sensor networks reporting soil moisture over spotty rural cellular, building-automation systems talking to a cloud dashboard, and student thesis prototypes where an ESP32 needs to stream data without draining its battery in an afternoon. In every one of those cases, the same 1999 pipeline logic is doing the work: send little, send reliably, assume the network will misbehave.
That is the lesson worth taking from MQTT's history. The best protocols are not the ones with the most features; they are the ones forged against real constraints. If you are choosing a messaging layer for a connected product and want to get the architecture right the first time, get in touch with Fluidwire. We build IoT and web systems from silicon to cloud, and picking the right transport early is one of the highest-leverage decisions you will make.
Top comments (0)