What is MQTT?

The publish/subscribe model

HTTP is request/response — clients ask, servers answer. MQTT inverts this: publishers send messages to a broker; subscribers receive every message that matches their interest. The broker is the central piece that everyone connects to.

      Publisher              Broker              Subscriber
   ┌───────────┐         ┌────────────┐        ┌────────────┐
   │ sensor    │ ──────► │            │ ─────► │ dashboard  │
   │ publishes │  topic  │  MQTT      │ topic  │ subscribed │
   │ "23.5"    │ ──────► │  broker    │ ─────► │ to topic   │
   └───────────┘         └────────────┘        └────────────┘
                              ▲
                              │
                         ┌────────────┐
                         │ data lake  │
                         │ subscribed │
                         └────────────┘

Publishers do not know who is subscribed; subscribers do not know who is publishing. Both just need to know the broker address and the topic name. This decoupling is the killer feature for IoT: a device can publish its sensor data regardless of whether anyone is listening, and dashboards can be added or removed without touching the device firmware.

Topics: how subscribers find what they want

Topics are slash-delimited hierarchical strings:

sensors/floor1/zone-a/temperature
sensors/floor1/zone-a/humidity
sensors/floor2/zone-b/temperature
home/livingroom/light/state
factory/line3/conveyor/speed

Conventions:

• Hierarchies go from general to specific, left to right.
• Avoid leading slashes — they create an "empty" first level.
• Lowercase by convention; case-sensitive in fact.
• UTF-8 strings, up to 65535 bytes.

Wildcards in subscriptions

Publishers must use specific topics. Subscribers can use two wildcards:

• + (single-level wildcard): matches exactly one path segment.

  sensors/+/temperature
  matches: sensors/floor1/temperature, sensors/floor2/temperature
  NOT: sensors/floor1/zone-a/temperature

• # (multi-level wildcard): matches any number of trailing segments. Must be the last character.

  sensors/#
  matches: sensors/floor1/temp, sensors/floor1/zone-a/temp, sensors/anything/else
  NOT: factory/line3/sensor (different root)

The pattern: design topics so wildcards let consumers subscribe to natural groupings without enumerating every device.

The MQTT broker

The broker is a server that:

1. Accepts persistent TCP connections from publishers and subscribers.
2. Receives published messages, matches them against active subscriptions.
3. Forwards each message to every matching subscriber.
4. Persists retained messages.
5. Optionally stores messages for offline subscribers (per QoS level).
6. Handles authentication, ACLs, TLS termination.

Common broker implementations:

QoS: delivery guarantees

MQTT defines three Quality of Service levels for message delivery (covered in detail in MQTT QoS levels explained):

• QoS 0 (at most once): Fire and forget. No acknowledgment. Message may be lost. Lowest overhead.
• QoS 1 (at least once): Acknowledgment required; message may be delivered multiple times if ack is lost. Common default.
• QoS 2 (exactly once): Four-way handshake guarantees delivery exactly once. Highest overhead.

QoS is set per publish AND per subscribe. The effective QoS is min(publish QoS, subscribe QoS) — a QoS 2 publish to a QoS 0 subscriber is delivered at QoS 0.

Keep-alive: the heartbeat

MQTT connections are persistent. To detect when a connection has silently died (NAT timeout, dead device, network failure), MQTT uses an application-layer heartbeat. The client specifies a keep-alive interval when connecting:

• If no message has been sent in the last keep-alive interval, the client sends a PINGREQ.
• The broker replies with PINGRESP.
• If 1.5× keep-alive elapses with no traffic from the client, the broker considers it dead and closes the connection.

Typical keep-alive values: 60 seconds for stable wired devices, 30 seconds for WiFi, 600 seconds for battery-constrained cellular IoT. Lower keep-alive detects failures faster but consumes more battery and data.

Last Will and Testament (LWT)

When a client connects, it can register a "last will" — a message the broker will publish on its behalf if the client disconnects unexpectedly (without a clean DISCONNECT). The will message has:

• A topic (often the device's status topic).
• A payload (often "offline" or similar).
• QoS and retain flag.

Use: presence detection. Every device publishes "online" to devices/{id}/status on connect (with retain=true). The LWT is set to publish "offline" to the same topic with retain=true. When the device disconnects cleanly, it publishes "offline" itself; when it crashes or loses network, the broker publishes the LWT. Either way, the topic always reflects current state, and subscribers see real-time presence.

Retained messages

By default, MQTT messages are ephemeral — only subscribers connected at publish time receive them. The retain flag makes a message sticky:

• Broker stores the retained message after delivering it.
• Any future subscriber to the topic immediately receives the last retained message.
• Each new retained publish replaces the previous.
• Publishing an empty payload with retain=true clears the retained message.

Use case: device state. Subscribers (dashboards, automations) coming online need to know the current state of devices that may not publish for hours. Retained messages give immediate access to current state without waiting for the next periodic publish.

MQTT 3.1.1 vs MQTT 5

The two protocol versions deployed today.

MQTT 3.1.1 (OASIS, 2014)

The dominant version still in 2026. Stable, broadly implemented, sufficient for most IoT use cases. Limitations:

• No reason codes — failures lack diagnostic detail.
• No per-message properties — metadata must be encoded in the payload.
• No request/response — pub/sub only.
• No topic aliases — every message includes the full topic string.

MQTT 5 (OASIS, 2019)

Backward-incompatible upgrade adding:

• Reason codes on every response — granular error reporting.
• User Properties — arbitrary key-value metadata on messages.
• Topic Aliases — replace long topic strings with integer aliases for repeated publishes.
• Message Expiry — TTL on individual messages.
• Shared Subscriptions — load balance messages across a group of subscribers.
• Request/Response pattern — built-in correlation IDs and response topics.
• Enhanced Authentication — SASL-like multi-step auth.

Adoption is growing but mixed — many devices still ship MQTT 3.1.1 only, and most existing infrastructure speaks both. New designs should target MQTT 5 if the broker and client libraries support it.

Security: TLS, authentication, ACLs

MQTT runs over TCP port 1883 (plaintext) and TCP port 8883 (TLS). Plaintext is acceptable only on isolated industrial networks; everything else should use TLS.

Authentication

• Username/password — simplest. Sent in the CONNECT packet.
• Client certificates (mTLS) — strong identity. Common in industrial / regulated IoT.
• JWT — used by some managed brokers (Google Cloud IoT used JWTs in its username field).
• OAuth / OIDC — via MQTT 5 Enhanced Authentication or broker-specific extensions.

Authorization (ACLs)

Brokers maintain ACLs specifying which clients can publish to which topics and subscribe to which topics. Granularity ranges from "this user can pub/sub to this exact topic" to wildcards like "device X can only pub to devices/X/*". Critical for multi-tenant deployments — without ACLs, any device can read or spoof any other device's data.

Throughput and scale

A single broker node can typically handle:

• 100K-1M concurrent connections (broker-dependent).
• 10K-100K messages per second.
• 1-10 GB/s total throughput on high-end hardware.

Clustering provides horizontal scale. EMQX clusters of 8+ nodes handle 50M+ concurrent connections. AWS IoT Core has no documented per-customer limit. For projects expecting millions of devices, broker selection and topology planning are major engineering inputs from day one.

The MQTT advantages for IoT

• Tiny wire format. 2-byte fixed header + variable payload. Compare HTTP's hundreds of bytes of headers per request.
• Persistent connection. One TCP+TLS handshake per device boot; messages flow indefinitely without per-message handshake cost.
• Server-initiated push. Subscribers receive messages without polling. HTTP requires WebSocket or long-polling for the same.
• QoS for unreliable networks. Cellular, mesh, satellite — MQTT handles intermittent connectivity with offline message queueing per QoS level.
• Topic-based routing. The broker handles fanout; publishers don't need to know subscribers.
• Last Will + retain. State management built into the protocol.

When MQTT is not the right choice

• One-shot HTTP requests. If your device wakes up, sends one reading, and sleeps for hours, HTTP POST is simpler than maintaining MQTT state.
• Browser clients. Browsers do not speak raw MQTT. Use MQTT-over-WebSocket (port 8084) or a different protocol entirely.
• Very constrained devices. Devices with under 10 KB of RAM may struggle with MQTT's connection state. Consider CoAP instead.
• Strict latency requirements. MQTT queueing adds milliseconds to per-message latency. For sub-millisecond real-time control, dedicated industrial protocols (EtherCAT, PROFINET) are more appropriate.

Frequently Asked Questions

What does MQTT stand for?

MQTT originally stood for "MQ Telemetry Transport" — IBM's MQ messaging product family plus telemetry transport. After OASIS standardization in 2014, the protocol kept the name MQTT but no longer expands to the original phrase officially. It is now treated as a proper name, like "HTTP" — the letters are the standard, not the words behind them.

What is the difference between MQTT and HTTP?

HTTP is request/response — clients pull data when they ask for it. MQTT is publish/subscribe via a broker — publishers push messages tagged with topics; subscribers receive every message matching their topic subscription without polling. MQTT is also more compact (binary header with 2 bytes of overhead vs HTTP's much larger text headers), persistent (one TCP connection per device with continuous bidirectional flow), and supports message-level delivery guarantees (QoS levels). For IoT devices needing low overhead and server-initiated messages, MQTT is purpose-built.

Do I need a public MQTT broker or can I run my own?

Both options work. Public/managed brokers (AWS IoT Core, Azure IoT Hub, Google Cloud IoT, HiveMQ Cloud, EMQ Cloud) are turnkey — connect devices, write subscribers, no infrastructure to manage. Self-hosted brokers (Mosquitto, EMQX, NanoMQ, VerneMQ) give full control and lower costs at scale, but require operations effort: HA, monitoring, scaling. For projects under ~10K devices, managed brokers are usually the better economic choice; above that, self-hosted starts winning on cost.

What is an MQTT topic wildcard?

MQTT topics are slash-delimited paths like sensors/floor1/temperature. Wildcards let you subscribe to multiple topics with one subscription. The plus sign (+) matches exactly one level: sensors/+/temperature matches sensors/floor1/temperature and sensors/floor2/temperature but not sensors/floor1/zone1/temperature. The hash sign (#) matches any number of trailing levels: sensors/# matches everything under sensors/. Wildcards are only valid in subscriptions, not in publish topics.

What is a retained MQTT message?

A retained message is one the broker stores after delivering it, so that any future subscriber to that topic immediately receives the last retained message on subscribe. Use case: device state. A thermostat publishes its current temperature with retain=true; when a new dashboard subscribes to its topic, the broker delivers the last temperature immediately rather than waiting for the next reading. Only one retained message exists per topic — each new retained publish replaces the previous.