An MQTT broker is a server that receives messages from publishing MQTT clients, matches each message topic against subscriptions, and delivers the message to subscribing clients. Publishers and subscribers do not need direct connections to one another: each connects to the broker, and one client can act as both publisher and subscriber.
The broker is the routing center of MQTT's publish-subscribe model. Depending on the protocol version, connection settings, and broker policy, it also authenticates clients, enforces topic permissions, tracks subscriptions and session state, applies Quality of Service (QoS) delivery flows, retains selected messages, and sends a client's Last Will after an ungraceful disconnect. These behaviors are defined by the OASIS MQTT 5.0 specification; a product's storage, scaling, observability, and availability are implementation and service concerns rather than guarantees of the protocol.
How does an MQTT broker work?
- A publisher and one or more subscribers establish separate MQTT connections to the broker. The broker accepts or rejects each connection and can authenticate the client.
- A subscriber sends a
SUBSCRIBEpacket containing a topic filter such asfactory/+/temperature. The broker records that subscription in the client's current or persistent session. - The publisher sends a
PUBLISHpacket with a topic name, payload, and QoS level. It does not address a subscriber directly. - The broker compares the topic name with active subscription filters, then forwards the publication to every matching subscription using the QoS rules that apply to each delivery.
- When configured session state survives a disconnect, the broker can preserve subscriptions and queue qualifying QoS 1 or QoS 2 messages for later delivery. Session behavior differs between MQTT 3.1.1 and MQTT 5 and must be configured deliberately.
For example, a sensor can publish to factory/line-1/temperature while a dashboard subscribes to factory/+/temperature. The broker performs the match and delivery; neither client needs the other's address. Follow the MQTT tutorial for a copy-ready connection, publish, and subscribe flow, or use the testing-only public MQTT broker with synthetic data for a disposable connectivity check.
MQTT protocol, broker, client, and managed broker
These terms describe different parts of the system:
| Term | What it is | What it is not |
|---|---|---|
| MQTT protocol | The wire-level rules for connecting, publishing, subscribing, acknowledgments, sessions, and disconnecting. | A server or hosting product. |
| MQTT broker | Server software that accepts MQTT client connections and routes publications to matching subscriptions. | The MQTT standard itself or a device SDK. |
| MQTT client | A device or application using an MQTT client library to connect; it may publish, subscribe, or do both. | Necessarily an end-user device—backend services are clients. |
| Managed MQTT broker | A provider-operated broker service that adds hosting, upgrades, monitoring, scaling, backups, and operational support. | A separate messaging protocol. |
If you need to learn the wire behavior, stay with this protocol overview and the MQTT QoS guide. For production threat boundaries, read the MQTT security guide. If you are choosing who operates the server, compare self-hosted and managed MQTT brokers. The RunMQTT homepage covers the managed cloud MQTT broker product; this article remains the protocol and broker concept guide.
From broker basics to MQTT 5 migration
MQTT 3.1.1 remains sufficient for many fleets. A move to MQTT 5 is worthwhile when the application is carrying too much custom logic for session lifetime, stale commands, error diagnosis, request-response correlation, or consumer coordination.
This is not a flag-day protocol upgrade. Brokers can commonly serve MQTT 3.1.1 and MQTT 5 clients at the same time, but each client connection negotiates one version. The safe approach is to migrate one client class and one feature at a time while keeping payload and topic contracts compatible.
Start with a migration reason, not a version number
Tie each MQTT 5 feature to an observed problem:
| Operational problem | MQTT 5 capability to evaluate |
|---|---|
| Offline sessions survive too long | Session Expiry Interval |
| Old commands arrive after reconnect | Message Expiry Interval |
| Connection failures look identical | Reason codes and reason strings |
| Clients exceed unknown broker limits | Server-advertised limits in CONNACK |
| Request-response uses custom payload fields | Response Topic and Correlation Data |
| Long topic names dominate small messages | Topic Alias |
| Consumers need bounded horizontal fan-out | Shared subscriptions |
Do not migrate solely to say the fleet uses MQTT 5. A smaller set of adopted, tested features is safer than enabling properties the application does not observe.
Inventory the compatibility path
Record the protocol support of every broker endpoint, device SDK, gateway, backend consumer, proxy, and test tool. Then capture behavior rather than relying only on a “supports MQTT 5” label:
- which properties the client can send and expose to application code;
- whether reconnects preserve the configured session semantics;
- whether the broker advertises limits the client respects;
- how logs and metrics expose reason codes;
- what happens when an MQTT 3.1.1 subscriber receives a message published by an MQTT 5 client.
Keep topics and payloads readable by both versions during the mixed-fleet period. MQTT 5 properties are not a substitute for a payload field that an older consumer still requires.
Separate Clean Start from session lifetime
MQTT 3.1.1 uses the Clean Session flag to combine two decisions: whether to discard an existing session at connect time and whether session state should remain after disconnect. MQTT 5 separates those concerns with Clean Start and Session Expiry Interval.
A migration should define the desired lifecycle explicitly:
| Client type | Clean Start | Session expiry | Intent |
|---|---|---|---|
| Stateless publisher | true | 0 | Never retain session state |
| Intermittent device | Usually false after first connect | Bounded interval | Restore subscriptions or queued QoS work briefly |
| Backend worker | Depends on subscription setup | Short and deliberate | Recover from process restarts without indefinite state |
Test the Session Present response. A client must know whether it needs to resubscribe instead of assuming the broker retained state.
Expire messages that lose value
Message Expiry Interval lets a publisher define how long a message remains useful. It is especially valuable for commands, temporary configuration, and high-rate telemetry that should not block current state after an outage.
Expiry does not replace application checks. Include an operation ID, issued time, and business deadline in a command payload, then reject stale or already-applied work on the device. The broker can prevent some late deliveries; the receiver remains the final safety boundary.
Turn reason codes and limits into operations data
MQTT 5 expands acknowledgments with reason codes and allows the server to advertise constraints such as Maximum Packet Size, Receive Maximum, Maximum QoS, Retain Available, and Shared Subscription Available.
Use that information instead of collapsing every failure into “connection lost.” Metrics should group stable reason codes, while logs may include bounded context such as client class and operation. Avoid putting raw credentials or unbounded topic values into telemetry.
A client also needs a defined response when the server limit is lower than its configuration: reduce the in-flight window, reject an oversized payload before publish, or fail deployment validation. Silently ignoring a negotiated limit creates intermittent production bugs.
Replace custom request-response conventions carefully
Response Topic and Correlation Data can represent a request-response exchange without inventing a new correlation field for every payload. The requester publishes a response destination and opaque correlation value; the responder returns that value with the result.
Authorization still applies. A device should not be able to choose an arbitrary response topic, and a backend service should not subscribe to an unbounded reply namespace. Timeouts, idempotency, and command expiry remain application responsibilities.
User Properties can carry small routing or tracing metadata, but keep the payload as the durable business contract when messages also flow into databases, MQTT 3.1.1 consumers, or non-MQTT systems.
Measure topic aliases before adopting them
Topic Alias replaces a repeated topic name with a connection-scoped integer after the mapping is established. It can reduce overhead when payloads are tiny and topic names are long.
The mapping does not survive reconnects, and inbound and outbound limits are negotiated separately. Treat aliases as a transport optimization, not a change to the topic model. Measure bytes and CPU on representative devices before accepting the additional client-state complexity.
Roll out one client class at a time
A controlled migration sequence is:
- enable MQTT 5 on a non-critical backend consumer;
- capture reason codes and server-advertised limits without changing behavior;
- add one feature, such as message expiry, to a canary topic family;
- test reconnects, broker restarts, rejected publishes, and mixed-version delivery;
- expand to one gateway or device cohort;
- keep rollback to MQTT 3.1.1 until the new behavior is observable in production.
Do not infer fleet compatibility from one successful publish. Exercise QoS acknowledgments, retained messages, Last Will, session restoration, authorization failures, oversized packets, and offline queues.
MQTT 5 migration exit checklist
Before making MQTT 5 the default:
- every client class has an explicit protocol version and fallback policy;
- session state has a bounded, tested lifetime;
- time-sensitive messages expire at both broker and application boundaries;
- reason codes reach dashboards and runbooks;
- clients respect server-advertised limits;
- MQTT 3.1.1 consumers still receive every required business field;
- rollback does not strand sessions, subscriptions, or queued commands.
MQTT broker FAQ
Is a broker required for MQTT?
Yes. MQTT's client-server architecture requires clients to connect to a broker, which receives publications and distributes them to matching subscriptions. A device-to-device application can run a broker on one device or gateway, but that process is still the MQTT broker; standard MQTT clients do not bypass it to publish directly to one another.
Does an MQTT broker store every message?
No. Normal delivery is driven by matching subscriptions and session state. A broker stores a retained message only when a publisher marks it retained, and it may queue eligible QoS 1 or QoS 2 messages for a disconnected client with a persistent session. Exact limits, expiry, and persistence behavior depend on MQTT settings and the broker implementation.
Should I self-host or use a managed MQTT broker?
Self-hosting gives your team direct control over infrastructure and broker configuration, but your team owns upgrades, scaling, monitoring, backups, incident response, and security hardening. A managed broker transfers much of that operational work to a provider. Evaluate both against workload isolation, compliance, availability objectives, operating skills, and total cost—not protocol compatibility alone.
What is the difference between an MQTT broker and an MQTT server?
In MQTT documentation, “server” is the protocol role and “broker” is the common product and architecture term for that role. Both refer to the component that accepts client connections and routes application messages; “managed broker” additionally describes who operates it and which service capabilities surround it.
Use the OASIS MQTT 5.0 specification as the normative reference. The MQTT QoS lab covers delivery handshakes, and the topic design guide covers the authorization contract that should remain stable during migration.