MQTT, CoAP, and AMQP are the three dominant messaging protocols for IoT systems, each optimized for different constraints and architectures. MQTT (Message Queuing Telemetry Transport) is a publish-subscribe protocol running over TCP that excels in bandwidth-constrained environments with its minimal 2-byte fixed header and three QoS levels (0: fire-and-forget, 1: at-least-once, 2: exactly-once). CoAP (Constrained Application Protocol) is a RESTful protocol built on UDP, designed for extremely resource-constrained devices with as little as 10 KB RAM, using a compact binary format and supporting multicast discovery. AMQP (Advanced Message Queuing Protocol) provides enterprise-grade message brokering with sophisticated routing, queuing, and transaction support, but requires significantly more resources. For most IoT sensor-to-cloud telemetry, MQTT is the default choice. CoAP suits constrained device-to-device communication in LLNs (Low-power Lossy Networks), while AMQP is ideal for backend message processing where reliability and complex routing are paramount.
How Does MQTT Work and When Should You Use It?
MQTT operates on a publish-subscribe model mediated by a central broker (such as Mosquitto, EMQX, or HiveMQ). Clients connect to the broker over TCP/TLS, subscribe to topic hierarchies using wildcards (sensors/+/temperature or sensors/#), and publish messages that the broker distributes to all matching subscribers. MQTT 5.0 added shared subscriptions for load balancing, message expiry intervals, topic aliases to reduce bandwidth, and response topics for request-response patterns. The protocol's persistent sessions allow devices to reconnect and receive missed messages without re-subscribing. MQTT-SN (Sensor Networks) extends MQTT to non-TCP transports like UDP and ZigBee. MQTT is the best choice when you need reliable bidirectional communication between constrained devices and cloud platforms, with AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all supporting MQTT natively.
What Makes CoAP Different from MQTT?
CoAP follows a client-server model similar to HTTP but is optimized for constrained networks. It uses UDP as its transport layer, eliminating TCP's connection overhead and three-way handshake. CoAP messages are compact—a minimal request is just 4 bytes of header plus payload. The protocol supports four message types: Confirmable (reliable), Non-confirmable (fire-and-forget), Acknowledgment, and Reset. CoAP includes built-in resource discovery via the .well-known/core endpoint, content negotiation, and the Observe extension for publish-subscribe-like behavior. DTLS provides security at the transport layer. CoAP is ideal for 6LoWPAN and Thread networks where UDP is the native transport, for devices with extremely limited RAM (under 10 KB), and for scenarios requiring multicast communication. However, CoAP lacks MQTT's built-in message queuing and broker-mediated fan-out.
# Python CoAP server example using aiocoap
import aiocoap
import aiocoap.resource as resource
class TemperatureResource(resource.Resource):
def __init__(self):
super().__init__()
self.temperature = 22.5
async def render_get(self, request):
payload = f"{self.temperature}".encode('ascii')
return aiocoap.Message(payload=payload,
content_format=0)
async def render_put(self, request):
self.temperature = float(request.payload.decode())
return aiocoap.Message(code=aiocoap.CHANGED)
# MQTT equivalent using paho-mqtt
import paho.mqtt.client as mqtt
client = mqtt.Client(protocol=mqtt.MQTTv5)
client.tls_set() # Enable TLS
client.connect("broker.example.com", 8883)
client.publish("sensors/room1/temperature", "22.5", qos=1)When Does AMQP Make Sense for IoT?
AMQP 1.0 is a binary wire protocol that provides rich messaging semantics including exchanges, queues, bindings, transactions, and message acknowledgments. Unlike MQTT's simple topic-based routing, AMQP supports direct, fanout, topic, and header-based exchange types, enabling complex routing topologies. The protocol guarantees message delivery through persistent queues and supports flow control to prevent consumer overload. AMQP is significantly heavier than MQTT or CoAP—a typical client library requires 100+ KB of RAM. This makes AMQP unsuitable for constrained MCUs but ideal for IoT gateway-to-cloud communication, industrial message buses, and backend microservice architectures. RabbitMQ and Apache Qpid are the most popular AMQP brokers. Azure IoT Hub and Azure Service Bus support AMQP as their primary protocol.
How Do These Protocols Compare on Key Metrics?
Protocol comparison across critical dimensions:
- Header overhead: MQTT has a 2-byte minimum fixed header, CoAP has a 4-byte base header, AMQP has an 8-byte minimum frame header. For small payloads (under 50 bytes), CoAP and MQTT are 10-50x more efficient than AMQP.
- Transport: MQTT uses TCP (reliable, ordered), CoAP uses UDP (lower latency, no connection state), AMQP uses TCP with SASL authentication. MQTT-SN and CoAP both work over non-IP transports.
- Security: MQTT uses TLS 1.2/1.3 over TCP, CoAP uses DTLS over UDP, AMQP uses TLS with SASL. All three support X.509 certificate-based authentication.
- Power consumption: CoAP is most power-efficient due to UDP's stateless nature. MQTT's TCP keepalives consume more power but can be tuned with long keep-alive intervals. AMQP has the highest power footprint.
- Scalability: MQTT brokers like EMQX handle 100M+ concurrent connections. CoAP is peer-to-peer without broker overhead. AMQP brokers like RabbitMQ typically handle 50K-100K connections per node.
Which Protocol Should You Choose for Your IoT Project?
For most IoT telemetry and command-control applications, MQTT is the pragmatic default. Its ecosystem is mature, every cloud platform supports it, client libraries exist for all MCU platforms, and QoS levels provide flexible reliability guarantees. Choose CoAP when your devices operate on 6LoWPAN or Thread networks, when you need multicast discovery, or when UDP is required due to network constraints. Choose AMQP when your architecture requires complex message routing, when transactions and guaranteed ordering are essential, or when integrating with enterprise messaging systems. Many production IoT systems combine multiple protocols: CoAP at the sensor layer, MQTT for device-to-gateway communication, and AMQP for backend processing pipelines.
Key takeaway: Use MQTT for most IoT sensor-to-cloud telemetry (mature ecosystem, every cloud platform supports it, QoS 0-2 flexibility). Use CoAP for extremely constrained devices on 6LoWPAN/Thread networks with UDP transport. Use AMQP for gateway-to-cloud and backend messaging requiring complex routing, transactions, and enterprise integration. Many production systems combine all three at different layers.
How Did We Choose Between MQTT and CoAP for a Real Project?
At EmbedCrest, we designed a smart building environmental monitoring system with 400 Thread-connected sensor nodes reporting temperature, humidity, CO2, and occupancy data. The initial architecture used MQTT over TCP, requiring each sensor node to maintain a TCP connection to the MQTT broker through the Thread Border Router. However, Thread's native transport is UDP (via 6LoWPAN), and maintaining TCP connections from 400 sleepy end devices created excessive overhead: each TCP connection required 1-2 KB of RAM for socket state, and TCP keepalives consumed 3x more power than the actual sensor data transmission. We switched to CoAP over UDP with the Observe extension for subscription-like behavior. CoAP's 4-byte header versus MQTT's minimum 2-byte header plus TCP overhead (20-byte TCP + 20-byte IP) reduced per-message overhead from 42+ bytes to 4 bytes, a 10x improvement significant for the 20-byte sensor payloads. The Thread Border Router ran a CoAP-to-MQTT bridge (implemented with libcoap and Paho MQTT-C), translating CoAP observations from the Thread mesh into MQTT publishes for Azure IoT Hub. This architecture reduced sensor node RAM usage by 40% and extended battery life by 2.5x compared to the MQTT-over-TCP approach.
What Are the Overlooked Protocol Selection Factors?
Beyond the standard comparison metrics, several factors are frequently overlooked. MQTT broker operational complexity matters at scale: a 100,000-device deployment requires broker clustering (EMQX, VerneMQ) with shared subscriptions for load balancing, persistent session storage for QoS 1/2 message durability, and careful tuning of keep-alive intervals to prevent connection storms after network outages. CoAP's blockwise transfer (RFC 7959) for large payloads adds significant complexity compared to MQTT's simple publish of arbitrary-length messages. AMQP's rich routing capabilities (exchange types, binding keys, dead-letter queues) simplify complex backend processing but require RabbitMQ or Apache Qpid expertise that is less common than MQTT knowledge. Also consider observability: MQTT brokers provide standardized $SYS topic trees for monitoring, while CoAP observability requires custom implementation. For regulatory compliance in healthcare or financial IoT, AMQP's transaction support enables exactly-once processing guarantees that MQTT QoS 2 approximates but does not provide at the application level.
How Do You Handle Protocol Migration in Production?
Protocol migration in a deployed fleet requires careful planning to avoid service disruption. Implement a protocol abstraction layer in your device firmware that encapsulates publish, subscribe, connect, and disconnect operations behind a transport-agnostic API. This allows switching from MQTT to CoAP or vice versa via a firmware update without rewriting application logic. On the server side, deploy protocol bridges that translate between protocols transparently: Eclipse Californium provides a CoAP-HTTP cross-proxy, and most MQTT brokers (EMQX, HiveMQ) support native protocol bridging. During migration, run both protocol endpoints in parallel for a transition period, verify data integrity by comparing messages received through both paths, then decommission the old endpoint after confirming all devices have migrated. This dual-running approach adds infrastructure cost but prevents data loss during the migration window. Budget 3-6 months for a complete fleet protocol migration including firmware development, testing, staged rollout, and validation.
