MQTT vs CoAP: which IoT messaging protocol to use
Short answer: Use MQTT when many devices report to many consumers through a broker over a reliable link; use CoAP when a small or sleepy device needs request-response or device-to-device messaging over UDP with no broker. Most fleets end up with MQTT at the center and CoAP, if anywhere, at the constrained edge.
MQTT vs CoAP compared for IoT devices: publish-subscribe over TCP against a REST-like protocol over UDP, delivery guarantees, power and when each one fits.
This article covers what each protocol does, the differences that decide between them, and where each one fits in a real system. It does not cover MQTT-SN, broker configuration, or CoAP's more specialized extensions beyond observe and block-wise transfer.
MQTT and CoAP are the two messaging protocols built for small devices, and they solve the same problem from opposite directions. One is a publish-subscribe protocol that needs a broker and a reliable connection. The other is a request-response protocol modeled on the web that runs over UDP and needs nothing in the middle. The choice follows from the shape of the communication, and this article sets out that shape for each.
How MQTT works
MQTT is a publish-subscribe protocol standardized by OASIS (MQTT 5.0; version 3.1.1 is still widely deployed). Every client connects to a broker over a long-lived TCP connection. A publisher sends a message to a named topic; the broker delivers it to every client subscribed to that topic. Publishers and subscribers never know about each other.
The features that matter for small devices are its three quality-of-service levels (fire and forget, at least once, exactly once), retained messages that give a new subscriber the last known value, a last-will message the broker publishes if a client vanishes, and persistent sessions that queue messages for a client that is away. The MQTT explainer goes through each.
MQTT’s cost is the connection. TCP needs a handshake and state on both ends, TLS adds another handshake, and keeping the connection alive needs periodic traffic. That is fine for a device that is always on and cheap for a device that connects, sends and disconnects, but it is real work for a device that wakes for a second every ten minutes.
How CoAP works
CoAP, the Constrained Application Protocol, is defined by the IETF in RFC 7252. It is a request-response protocol with the same shape as HTTP: a client sends GET, PUT, POST or DELETE to a resource identified by a URI on a server, and the server replies with a response code and a payload. The difference is that it runs over UDP with a compact binary header, so a request fits in a single small datagram and a device with a few kilobytes of memory can implement it.
Because UDP does not guarantee delivery, CoAP has its own reliability: a request can be marked confirmable, in which case the sender retransmits until it gets an acknowledgment, or non-confirmable, in which case it is sent once. The observe extension turns request-response into notification: a client registers interest in a resource and the server sends a message whenever it changes, which gives CoAP a lightweight version of what MQTT does with subscriptions. Block-wise transfer carries payloads larger than one datagram, such as a firmware image, in numbered pieces.
Security is DTLS, the datagram version of TLS. CoAP also has a mapping to TCP and WebSockets (RFC 8323) for networks that block UDP, though that gives up some of the reasons for choosing it.
CoAP’s cost is the absence of a middle. Every client must be able to reach every server it talks to, which is simple on a local network and complicated across the internet, where devices sit behind address translation and firewalls. A proxy or a gateway usually fills that gap, and at that point the design starts to look like it has a broker after all.
MQTT vs CoAP: the differences that matter
| MQTT | CoAP | |
|---|---|---|
| Model | Publish-subscribe through a broker | Request-response, client to server, plus observe |
| Transport | TCP (TLS for security) | UDP (DTLS for security); TCP mapping exists |
| Middle box | Broker required | None required; proxy optional |
| Delivery guarantees | QoS 0, 1, 2 per message | Confirmable or non-confirmable per message |
| State per device | A connection held open, or reconnected each time | None between requests |
| Message size | Small header; payloads up to large limits | One datagram by default; block-wise for larger |
| Discovery | None built in; topics are convention | Resource discovery built in |
| Fan-out to many consumers | Native | Not native; needs a proxy or the application |
| Works through NAT and firewalls | Yes, device connects outward | Awkward without a proxy |
| Suits | Fleets reporting to back ends, dashboards, alerts | Constrained devices, local networks, device-to-device |
The decisive rows are the model, the transport and the middle box. MQTT assumes many producers and many consumers with a broker between them, over links that can hold a connection. CoAP assumes a client that knows which server it wants, over links where a single datagram is all it can afford. Everything else in the table follows from those three.
Power is a consequence rather than a row of its own. A CoAP device can send one datagram and sleep, with no connection to set up or tear down. An MQTT device pays for a TCP and TLS handshake on each connection, which for a sleepy device is most of its awake time; MQTT with a persistent session and a long keep-alive reduces that cost if the device can afford to stay connected. On a mains-powered device the difference is irrelevant.
When to use MQTT
Use MQTT when the system is a fleet reporting to a back end: sensors and gateways publishing readings, and a historian, a dashboard, an alert engine and an analytics service all subscribing. The broker is what makes adding a consumer free, and that property is worth the connection cost. It is the right choice for gateways, for mains-powered devices, for cellular devices that can hold a connection, and for anything where the consumers are not known in advance.
It is also the protocol the rest of the world expects. Cloud IoT services, industrial gateways and home controllers all speak it, and the industrial pattern of OPC UA at the machine and MQTT above it, described in the OPC UA and MQTT article, is built on it. A device that speaks MQTT plugs into that world with no translation.
When to use CoAP
Use CoAP when the device is genuinely constrained (a few kilobytes of memory, a battery, a radio that carries one small datagram at a time) and the communication is request-response or device-to-device on a local network. A sensor that a gateway polls, an actuator that a controller commands, a group of devices on a Thread network talking to each other: all fit CoAP’s shape. Thread and 6LoWPAN networks in particular were designed with CoAP in mind, and several device-management standards for cellular IoT devices run over it, which is why NB-IoT modules often speak CoAP before they speak MQTT.
CoAP also fits where a broker would be a single point of failure the site cannot afford, or where the only network is the local one and there is nothing to fan out to.
Using MQTT and CoAP together
The two are not exclusive, and the usual arrangement is layered. Constrained devices speak CoAP to a gateway on the local network; the gateway speaks MQTT to the broker on behalf of all of them. The devices get the protocol built for their limits, the back end gets the fan-out and the ecosystem, and the gateway does the translation once. That is the same pattern the edge computing article describes for processing: do the constrained work close to the device and hand a cleaner stream upward.
Whichever you choose, the protocol is the smaller decision. Payload format, topic or resource naming, security credentials and firmware update paths are what a fleet lives with for years, and both protocols leave all of those to you. Pick the protocol from the shape of the communication, then spend the effort where it lasts.
Written by the IoT Crest editorial team. Facts in this article follow the editorial policy: only well-established behavior is stated and no figures are invented.