MQTT vs AMQP
MQTT and AMQP are both message-oriented middleware protocols but serve different niches. MQTT prioritizes simplicity and low overhead – a CONNECT packet is 14 bytes, making it viable for microcontrollers on cellular networks. AMQP provides enterprise messaging features: exchanges with configurable routing (direct, topic, fanout, headers), durable queues, transactions, and message acknowledgment with redelivery. The choice depends on your constraints: if devices have 256KB RAM and communicate over expensive cellular links, MQTT is correct. If you need message routing, dead-letter queues, priority ordering, and transactional guarantees between services, AMQP provides these natively without application-layer implementation.
MQTT is a lightweight publish-subscribe protocol designed for constrained IoT devices with minimal bandwidth. AMQP is a feature-rich message broker protocol with guaranteed delivery, routing, and transactions. Use MQTT for IoT telemetry; use AMQP for enterprise messaging where routing flexibility and reliability matter.
| Feature | MQTT | AMQP |
|---|---|---|
| Design goal | Minimal overhead for constrained IoT devices | Feature-rich enterprise messaging with routing |
| Protocol overhead | 2-byte minimum header, 14-byte CONNECT | 8-byte minimum frame header, complex negotiation |
| Message routing | Topic-based only (hierarchical with wildcards) | Exchanges: direct, topic, fanout, headers routing |
| QoS levels | QoS 0 (fire-forget), QoS 1 (at-least-once), QoS 2 (exactly-once) | At-most-once, at-least-once (with ack), exactly-once (with transactions) |
| Message persistence | Retained messages (last value only per topic) | Durable queues (full history until consumed) |
| Broker complexity | Simple (Mosquitto runs on Raspberry Pi) | Complex (RabbitMQ needs 256MB+ RAM minimum) |
| Connection model | Long-lived TCP with keep-alive pings | Long-lived TCP with heartbeat frames |
| Dead letter handling | Not supported natively | Dead-letter exchanges built-in |
| Transactions | Not supported | Multi-message transactions supported |
| Security | TLS + username/password or client certs | TLS + SASL (PLAIN, EXTERNAL, SCRAM) |
| Typical payload | Sensor readings, telemetry (bytes to KB) | Business events, commands (KB to MB) |
When to use MQTT
Use MQTT for IoT device telemetry, home automation (Zigbee2MQTT, Home Assistant), fleet vehicle tracking, industrial sensor networks, and any scenario where devices have limited RAM/CPU/bandwidth. MQTT 5.0 adds request-response patterns, shared subscriptions, and message expiry.
When to use AMQP
Use AMQP (RabbitMQ, Apache Qpid) for microservice event buses, order processing pipelines, financial transaction messaging, task queues (Celery), and any system needing complex routing (route orders to different processors by region/priority), dead-letter handling, and message TTL with requeueing.
Common Mistakes
- Using AMQP for IoT sensor data – the protocol overhead and broker memory requirements are excessive for thousands of constrained devices publishing small payloads.
- Using MQTT for inter-service communication without implementing application-layer routing – MQTT topic hierarchies are less flexible than AMQP exchanges for complex routing patterns.
- Assuming MQTT QoS 2 (exactly-once) is free – it requires 4 packets per message and doubles broker storage. Use QoS 1 with idempotent consumers instead.
- Running RabbitMQ without monitoring queue depth – unbounded queues exhaust memory and crash the broker. Set x-max-length or x-overflow policies.
FAQ
Can RabbitMQ speak MQTT?
Yes. RabbitMQ includes an MQTT plugin that maps MQTT topics to AMQP exchanges. IoT devices connect via MQTT while backend services consume via AMQP – the broker bridges both protocols.
Which is faster?
MQTT has lower per-message overhead (smaller headers, simpler routing). For raw throughput with large messages, the difference is negligible – both are limited by TCP and broker I/O.