MQTT broker vs message queue is a distinction that trips up many teams, because both are "message brokers" that sit between producers and consumers. The difference is in delivery semantics: an MQTT broker copies each message to every interested subscriber right now, while a message queue holds each message until exactly one consumer takes responsibility for it. This guide explains both models, compares them with RabbitMQ- and SQS-style queues, and shows when a cloud MQTT broker is the right building block.
Two Delivery Models
Topic-based publish/subscribe (MQTT). A publisher sends a message to a topic such as plant1/line2/press4/temperature. The broker looks at every current subscription, finds the ones whose filters match, and delivers a copy to each. If five services subscribe, five copies go out. If nobody subscribes, the message is dropped, unless it is retained as the topic's last value or queued in a persistent session. The broker's job is routing, not storage. For a deeper look at the model, see the MQTT publish/subscribe model.
Point-to-point queues (RabbitMQ, SQS and similar). A producer sends a message to a queue. The message waits there, durably, until a consumer receives it. With several consumers on the same queue, each message goes to only one of them; they compete for work. The consumer acknowledges after processing, and if it crashes before acknowledging, the message becomes visible again for another consumer. The queue's job is to make sure each unit of work is done once by someone.
The shorthand: MQTT answers "who needs to know about this?", and a queue answers "who will do this job?".
MQTT Broker vs Message Queue Compared
| Aspect | MQTT broker | Message queue (RabbitMQ, SQS style) |
|---|---|---|
| Delivery | Copy to every matching subscriber | Each message to one consumer |
| Addressing | Hierarchical topics, wildcards + and # |
Named queues (plus exchanges and bindings in RabbitMQ) |
| Message created with no consumer | Dropped, unless retained or held for a persistent session | Stored until consumed or expired |
| Storage | Last retained value per topic, per-client session queues | Durable queues, often with long retention |
| Acknowledgment | QoS 1 and 2 between client and broker | Consumer ack after processing, redelivery on failure |
| Work distribution | Shared subscriptions in MQTT 5 | Native competing consumers |
| Dead-letter handling | Not part of MQTT | Common feature (dead-letter queues and exchanges) |
| Ordering | Per topic per client session | Per queue, with caveats when redelivery occurs |
| Delivery mode | Push to connected clients | Push (RabbitMQ) or pull/long poll (SQS) |
| Client footprint | Tiny, runs on microcontrollers | Server-class SDKs |
| Presence and state | Keep alive, Last Will, retained messages | Not applicable |
| Typical use | Device telemetry, commands, live state, dashboards | Background jobs, order processing, decoupled microservices |
Where the Models Overlap
The line is not perfectly sharp, which is part of the confusion.
MQTT has two queue-like features. A persistent session makes the broker queue QoS 1 and 2 messages for one client while it is offline; with MQTT 5 you bound that with a session expiry interval. Shared subscriptions ($share/group/filter) let several clients in a group split a topic's messages so each message reaches one member of the group, which is exactly competing-consumer behavior. Read MQTT shared subscriptions and MQTT persistent session for details.
Queue systems, in turn, offer pub/sub. RabbitMQ's fanout and topic exchanges copy a message into several queues, and cloud services pair a notification topic with multiple queues for fan-out. But each subscriber still needs its own queue declared in advance.
So the real question is not which features exist, but which model is native. MQTT is native fan-out with lightweight, dynamic subscriptions; queues are native durable work distribution.
See the Difference in Two Minutes
You can watch fan-out on the free public MQTT broker with the mosquitto clients. Use a unique prefix so you do not see anyone else's messages.
PREFIX="connectmq/demo/$(openssl rand -hex 4)"
# Fan-out: run this in two terminals, each with a different client ID
mosquitto_sub -h broker.connectmq.com -V mqttv5 -i fan-$RANDOM \
-t "$PREFIX/orders/new" -v
# Publish five messages, slowly enough for the per-client rate limit
for i in 1 2 3 4 5; do
mosquitto_pub -h broker.connectmq.com -V mqttv5 -i pub-$RANDOM -q 1 \
-t "$PREFIX/orders/new" -m "order $i"
sleep 0.5
done
Both subscribers print all five orders. For the queue-like behavior you need a broker plan with shared subscriptions, such as a paid Serverless broker on ConnectMQ. Start two workers with your own credentials (each worker needs its own client ID and matching credentials from the portal) and publish again:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t '$share/workers/orders/new' -v
The two shared-subscription workers split the messages, so each prints only some. Then stop both workers, publish again and start them back up: the orders published while they were offline are gone. Only a persistent session would have held them, and even then only for that one client and only within the session expiry interval. That is the gap a real queue fills.
When to Use an MQTT Broker
An MQTT broker is the right building block when:
- Producers are devices. Sensors, PLC gateways, vehicles, mobile apps and browsers need small clients and tolerant connection handling.
- Many consumers need the same data. A reading goes to a dashboard, a historian writer and an alerting service at once, and adding a fourth consumer requires no change to the producer.
- Current state matters more than history. Retained messages give every new subscriber the last known value instantly.
- You need presence. Keep alive and Last Will tell you when a device goes offline.
- You need to push commands to specific devices behind NAT or on cellular links.
If you are new to brokers in general, what an MQTT broker does covers the basics, and the MQTT tutorial walks through topics, QoS and sessions.
When to Use a Message Queue
A queue is the right building block when:
- Each message is a job that must be processed exactly once by one worker, such as generating an invoice or resizing an image.
- Work must survive long outages of consumers, for hours or days.
- You need retries and dead-letter handling for messages that repeatedly fail.
- Producers and consumers are backend services on reliable networks.
Using Both Together
Most IoT platforms end up with both. Devices publish to an MQTT broker. A consumer service subscribes, typically through a shared subscription so it can scale out, filters the stream down to the events that need processing, for example "alarm raised" or "batch completed", and enqueues those as jobs in RabbitMQ or SQS. Live telemetry keeps flowing to dashboards over MQTT, while durable business workflows run off the queue. The MQTT vs AMQP article includes a working bridge in Python.
When choosing the MQTT side, decide whether to run it yourself or use a cloud MQTT broker. ConnectMQ is a managed broker with MQTT 3.1.1 and 5.0, TLS, retained messages, session expiry and, on the paid Serverless plan, shared subscriptions, plus multi-tenant isolation and per-plan quotas. It is a broker, not a queue: it has no built-in queue bridge, so your consumer service does the hand-off, which keeps the boundary explicit.
Get Started with ConnectMQ
Use an MQTT broker for what it does best, fan-out, live state and device connectivity, and pair it with a queue when you need durable jobs. Create a free Serverless broker at app.connectmq.com, no credit card required, and try the fan-out and shared subscription demo above on your own private broker.
Frequently Asked Questions
Is an MQTT broker a message queue?
Not in the classic sense. An MQTT broker routes copies of each message to all current subscribers, while a queue stores each message until one consumer processes it. MQTT has queue-like features but is pub/sub at heart.
Can MQTT guarantee a message is processed only once?
QoS 2 guarantees exactly-once delivery between a client and the broker, not end-to-end processing. For once-only processing of jobs, use idempotent consumers or hand the work to a message queue.
What happens to MQTT messages when no one is subscribed?
They are discarded, unless the message is retained, in which case the broker keeps it as the topic's last value, or a persistent session exists for an offline subscriber.
Should I use RabbitMQ or an MQTT broker for IoT devices?
Connect devices to an MQTT broker, which is built for many lightweight, intermittent clients. Use RabbitMQ behind it for backend work queues if your workflows need them.
