Both MQTT and CoAP target constrained IoT environments, yet they make different architectural decisions: MQTT typically relies on TCP and a central broker, while CoAP is commonly used over UDP and follows a lightweight client/server request-response model. Choosing the wrong one can affect bandwidth, battery life, operational complexity, or scalability.
MQTT vs. CoAP: key takeaways
- MQTT uses TCP, a 2-byte header, and broker-based pub/sub routing, making it the default protocol for IIoT and edge-to-cloud architectures at scale.
- CoAP uses UDP, a 4-byte header, and REST semantics for highly constrained devices. In very small embedded environments, a full TCP-based stack may be impractical depending on memory, software stack, and communication requirements.
- CoAP and MQTT complement each other: CoAP handles the most constrained device tier, MQTT takes over at the gateway and routes data to cloud, SCADA, and analytics systems.
- The Cedalo MQTT Platform extends Eclipse Mosquitto with clustering, RBAC, certificate management, and a centralized Management Center for production-grade IIoT deployments.
What are MQTT and CoAP? Core definitions at a glance
MQTT (Message Queuing Telemetry Transport) is a lightweight, TCP-based messaging protocol standardized under ISO/IEC 20922. It uses a publish/subscribe model through a central broker: publishers send data to topics, and the broker distributes it to all active subscribers. MQTT was built for unreliable networks and resource-limited devices, with a minimum fixed header of just 2 bytes.
CoAP (Constrained Application Protocol) is a RESTful application protocol standardized by the IETF in RFC 7252. It runs over UDP and follows a request/response pattern comparable to HTTP (GET, PUT, POST, DELETE) but with a 4-byte base header designed for microcontroller-class hardware. CoAP targets scenarios where even a TCP stack exceeds the available memory.
What are the key differences between MQTT and CoAP?
The MQTT vs. CoAP comparison covers five structural dimensions: transport layer, messaging model, protocol overhead, security, and scalability. Here is the full technical breakdown:
| Dimension | MQTT | CoAP |
|---|---|---|
| Transport | TCP | UDP |
| Messaging model | Publish/Subscribe (broker-based) | Request/Response (peer-to-peer) |
| Base header size | 2 bytes | 4 bytes |
| QoS levels | 0, 1, 2 | Confirmable / Non-Confirmable |
| Security | TLS / mTLS | DTLS |
| Multicast support | No (broker-routed) | Yes (native UDP multicast) |
| Broker required | Yes | No |
| Persistent sessions | Yes | No |
| Observe / streaming | Native pub/sub | Observe extension (RFC 7641) |
| Primary use case | IIoT, edge-to-cloud, smart factory | Ultra-constrained M2M, local networks |
How do MQTT and CoAP differ in their transport layer?
| MQTT · TCP | CoAP · UDP |
|---|---|
| Connection state + ordered delivery | No TCP handshake, faster session establishment |
| Automatic retransmission on packet loss | Confirmable (CON): receiver ACKs, sender retransmits on timeout |
| Persistent sessions: queued messages survive disconnects | Non-Confirmable (NON): fire-and-forget, equivalent to MQTT QoS 0 |
| Last Will & Testament (LWT): broker notifies peers on drop | Lower per-session memory footprint |
| Ideal for unstable WAN / cellular links | Suited for stable local networks |
LWT in practice
When a field device loses power mid-shift, the broker publishes a pre-configured offline status to all subscribers, no polling loop required.
How does the messaging model of MQTT compare to CoAP’s request/response pattern?
| MQTT · Publish / Subscribe | CoAP · Request / Response |
|---|---|
| Publishers and subscribers fully decoupled | Client addresses server directly by IP + port |
| Broker handles all routing via topic strings | Supports GET, PUT, POST, DELETE (REST semantics) |
| Example: factory/hall3/machine12/temp | Observe extension (RFC 7641): limited push updates |
| Wildcards (+, #) aggregate multiple data streams | No broker required, lower infrastructure overhead |
| Fan-out: one message to thousands of subscribers | Fan-out needs explicit multicast addressing |
CoAP Observe
CoAP Observe is not a full pub/sub replacement, it tracks one resource per subscription and lacks wildcard-based topic routing across many devices simultaneously.
How does protocol overhead compare between MQTT and CoAP?
| MQTT fixed header | CoAP base header | HTTP header (min) |
|---|---|---|
| 2 B | 4 B | ~200 B |
| MQTT · Overhead profile | CoAP · Overhead profile |
|---|---|
| 2-byte fixed header, minimal per-message cost | 4-byte base header + variable-length Options |
| Session-based: no connection setup per message | URI paths, content formats, observe tokens add overhead |
| Topic string length adds to every packet, keep topics short | Stateless: no persistent connection cost |
| QoS 2 adds a 4-step handshake, use only where exact-once matters | Better for sporadic reads/writes than high-frequency streams |
Optimization tip
In MQTT, a short topic like f/h3/m12/t versus factory/hall3/machine12/temperature saves bytes. At 100 ms intervals across 10,000 devices these accumulate to significant WAN bandwidth savings.
MQTT vs. CoAP vs. HTTP: what changes when you add the third protocol?
Many architects evaluate MQTT vs. CoAP vs. HTTP together, especially when designing systems that span from constrained edge devices to cloud APIs. Here is how the three protocols compare across the dimensions that matter for IoT system design:
| Dimension | MQTT | CoAP | HTTP |
|---|---|---|---|
| Transport | TCP | UDP | TCP |
| Header overhead | Very low (2 bytes) | Low (4 bytes) | High (hundreds of bytes) |
| Connection model | Persistent | Connectionless | Short-lived (HTTP/1.1) |
| Messaging pattern | Pub/Sub | Request/Response | Request/Response |
| Broker required | Yes | No | No |
| Typical use | IIoT, edge-to-cloud | Ultra-constrained M2M | Backend APIs, cloud services |
| Firewall friendliness | Requires port 1883/8883 | Requires port 5683/5684 | Port 80/443 (universal) |
CoAP deliberately mirrors HTTP’s REST semantics, which makes it easier to proxy CoAP traffic into HTTP-based backend services. A CoAP-to-HTTP proxy translates device requests into REST API calls without a full broker in between.
HTTP itself remains relevant for backend-to-backend communication, dashboard APIs, and cloud service integrations, but its comparatively higher overhead often makes it less suitable for large-scale communication with highly constrained devices.
MQTT vs. AMQP vs. CoAP: how do the three protocols position themselves?
MQTT, CoAP, and AMQP occupy distinct positions in the messaging stack:
| Protocol | Stack position | Primary strength | Typical environment |
|---|---|---|---|
| CoAP | Device layer | Ultra-low overhead, no TCP stack needed | Microcontrollers, local M2M |
| MQTT | Edge-to-cloud | Scalable pub/sub, persistent sessions, IIoT-ready | Industrial gateways, IIoT platforms |
| AMQP | Backend / enterprise | Transactional messaging, complex routing, durable queuing | ERP integration, enterprise services |
In practice, many IIoT architectures use these protocols in a layered way rather than choosing one for everything. CoAP can serve the most constrained device tier where a lightweight UDP-based approach is appropriate. MQTT often bridges the edge to the cloud with a scalable broker layer. AMQP is commonly used for transactional or integration-heavy messaging in enterprise backends.
For a deeper technical breakdown of the CoAP protocol itself, including its observe mechanism and DTLS implementation options, see the Cedalo CoAP protocol guide.
When should you use MQTT, and when does CoAP make more sense?
When is MQTT the right choice for your IoT project?
MQTT fits any scenario where you need persistent connectivity, scalable message routing, and reliable data delivery across an unstable network.
Concrete indicators:
- Your devices run on Linux-based gateways or microcontrollers with sufficient RAM for a TCP stack (typically 8 KB or more)
- You need fan-out: one sensor feeds multiple downstream consumers simultaneously
- Your architecture includes a Unified Namespace (UNS) or topic-based data model
- You require QoS 1 or QoS 2 delivery guarantees for command-and-control messages
- You operate at scale: hundreds to millions of concurrent device connections
- Your use case falls into IIoT, smart factory, predictive maintenance, energy monitoring, or logistics tracking
When does CoAP have advantages over MQTT?
CoAP has a clear edge where MQTT’s TCP dependency becomes a hard constraint.
Key scenarios where CoAP is the right choice:
- Devices with less than 8 KB RAM that cannot run a TCP stack.
- Local M2M communication without broker infrastructure.
- Sporadic on-demand reads where a persistent MQTT connection adds unnecessary overhead.
Work through the decision framework below to identify which scenario applies to your architecture.
Can MQTT and CoAP work together in one architecture?
Yes, and this combination solves the constraint mismatch at different hardware tiers. A CoAP device communicates with a local gateway over UDP. The gateway translates CoAP payloads into MQTT messages and forwards them to an MQTT broker. From the broker, data flows to cloud systems, analytics platforms, or SCADA integrations.
This layered pattern is common in smart metering, building automation, and remote sensor networks where the field devices are too constrained for TCP, but the backend infrastructure runs on standard MQTT-based IIoT platforms.
Security in MQTT vs. CoAP: what do the differences mean in practice?
MQTT security builds on TLS over TCP, with mTLS adding client certificate authentication for zero-trust device identity. Beyond transport encryption and authentication, the MQTT specification leaves authorization to the broker: enterprise brokers add RBAC to restrict topic-level access and audit trails to support compliance with frameworks such as ISO 27001 or IEC 62443. This is exactly where Pro Mosquitto comes in, with role-based dynamic security and audit logging managed centrally through the Cedalo Management Center.
CoAP relies on DTLS, TLS adapted for UDP. On hardware below 32 KB RAM, DTLS often exceeds available resources. OSCORE (RFC 8613) offers a lighter alternative at the application layer, but its ecosystem remains significantly less mature than MQTT’s TLS infrastructure.
MQTT vs. CoAP: the decision framework for IoT and IIoT projects
Work through these five steps before committing to either protocol in your architecture:
- Check hardware class. Does the target device support a TCP stack? If RAM is below ~8 KB or no TCP/IP library is available, CoAP is the starting point. If the device runs an RTOS or Linux-based OS with networking support, MQTT is viable.
- Define the communication pattern. Does the architecture require continuous telemetry streams with fan-out to multiple consumers? MQTT. Does it need occasional on-demand reads or writes to individual devices? CoAP’s request/response model fits.
- Assess network conditions. Is the connection to a stable LAN or local subnet? CoAP’s UDP works reliably. Does the device connect over WAN, cellular, or an unstable radio network? MQTT’s persistent sessions and QoS levels handle reconnects and message queuing without application-layer logic.
- Estimate scale. How many concurrent device connections does the system need to handle? MQTT brokers scale horizontally to millions of connections. CoAP peer-to-peer communication does not require a broker but has no centralized routing, which complicates fan-out at scale.
- Weigh security requirements against implementation effort. Does the deployment require mTLS, RBAC, and audit logging? MQTT with an enterprise broker delivers this with manageable operational overhead. Does it require DTLS on constrained hardware? Evaluate whether OSCORE is sufficient or whether the security requirements push the architecture toward an MQTT-gateway pattern instead.
For many IIoT projects, including smart factory, predictive maintenance, and edge-to-cloud architectures, MQTT is a strong default candidate. CoAP is particularly relevant for constrained device classes and network environments where a lightweight UDP-based approach is more appropriate than a TCP-based messaging stack.
The broker layer determines whether your IoT architecture delivers
CoAP solves the device communication problem. What happens at the broker layer determines whether that data reaches the right systems: reliably, securely, and at scale. A broker without clustering, access control, or operational visibility becomes the bottleneck in an architecture that was designed to be lean.
The Cedalo MQTT Platform builds on Eclipse Mosquitto and extends it with additional capabilities for IIoT production environments, including features for centralized management, security, and scalable operation.
Your advantages with Cedalo:
- CoAP device data can flow through a centrally managed MQTT backbone to MES, SCADA, analytics, and cloud systems. This can reduce integration complexity and data silos between OT and IT.
- Clustering and load balancing improve resilience under peak load and partial node failures. A fault at one site does not have to disrupt data flow elsewhere.
- mTLS, RBAC, and audit trails can support security architectures that are aligned with ISO 27001 and IEC 62443 objectives, while reducing the need for additional custom security components at the broker layer.
- The Cedalo Management Center provides real-time monitoring, multi-broker control, and structured troubleshooting across all sites from a single interface.
Run your MQTT infrastructure the way production demands
Open-source Mosquitto runs many production workloads well. When you need clustering for high availability, centralized management, or enterprise authentication, the Cedalo Platform adds them on the Mosquitto foundation.
MQTT vs. CoAP: frequently asked questions
What is the maximum message size for CoAP compared to MQTT?
CoAP is optimized for small UDP messages. MQTT typically supports much larger payloads, limited by the protocol, broker, client, and available memory. As a result, MQTT is usually more flexible for variable industrial payloads.
Does MQTT 5.0 reduce the gap between MQTT and CoAP for constrained devices?
MQTT 5.0 introduces session expiry intervals, reason codes, and shared subscriptions, but it does not eliminate the TCP dependency that makes CoAP necessary on the most constrained hardware. For devices with enough resources to run TCP, MQTT 5.0 adds operational features that CoAP’s request/response model cannot match.
Which industries actively deploy CoAP in production today?
CoAP sees production use primarily in smart metering, building automation, and low-power wide-area network (LPWAN) deployments where devices run on coin-cell batteries for years. In automotive, manufacturing, and logistics, MQTT dominates because the existing gateway infrastructure already supports TCP and broker-based architectures.
How does Cedalo handle CoAP device data in production architectures?
Cedalo does not implement the CoAP protocol directly, but in many architectures it can remove the need for a separate CoAP-specific central messaging layer. A lightweight CoAP-to-MQTT gateway at the device layer forwards data to the Cedalo broker, which then handles security, fan-out, and system integration centrally.
