If you are picking a messaging protocol for a new system, MQTT and AMQP are two of the most commonly-considered candidates. Both are mature, both have large ecosystems, and both are used in production at very large scale. But they were designed for different problems, and the comparison is more nuanced than most articles suggest — because AMQP is not one protocol, it is two, and choosing “AMQP” without knowing which version means very little.
This article covers all three: MQTT, AMQP 0.9.1 (the version most people mean when they say “AMQP,” used by RabbitMQ), and AMQP 1.0 (the OASIS and ISO standard, used by Azure Service Bus, IBM MQ, Apache ActiveMQ, and others). It is deliberately neutral: MQTT wins on some axes, AMQP wins on others, and pretending otherwise helps no one. It is written to help you pick the right protocol for your actual use case, not to sell you on any particular one.
Table of Contents
The three protocols at a glance
| Aspect | MQTT | AMQP 0.9.1 | AMQP 1.0 |
|---|---|---|---|
| Standardized | OASIS (2014, MQTT 3.1.1) / OASIS (2019, MQTT 5) | Not an OASIS standard (informal spec) | OASIS Standard (2012), ISO/IEC 19464 |
| Wire format | Binary, compact | Binary | Binary |
| Model | Publish/subscribe with broker | Publisher → exchange → queue → consumer (broker mandatory) | Peer-to-peer messaging (broker optional) |
| Server model in spec | Not defined in detail; broker implementations vary | Fully defined (exchanges, queues, bindings, exchange types) | Not defined (protocol only) |
| Header overhead (per message) | As small as 2 bytes | Larger (frame + method headers) | Larger (performative + descriptor) |
| Delivery guarantees | QoS 0/1/2 (built into protocol) | Publisher confirms + consumer acks (broker-mediated) | Delivery states + settlement (peer-to-peer) |
| Topic hierarchy | UTF-8 with /, wildcards + and # | Routing keys, matched by exchange types | Address-based, resolution up to implementation |
| Client-server relationship | Simple: connect to broker, publish/subscribe | Client knows broker topology (declares exchanges/queues) | Peers exchange messages; no assumed topology |
| Primary use case | IoT, telemetry, constrained devices | Enterprise messaging, complex routing (RabbitMQ) | Enterprise messaging, cross-vendor interoperability |
| Backward compatibility | MQTT 5 is not wire-compatible with 3.1.1 | Independent from AMQP 1.0 | Independent from AMQP 0.9.1 |
The rest of this article expands on each of these differences and helps you decide which protocol fits which situation.
First, the AMQP naming problem
Before comparing, one point has to be settled clearly, because it causes real confusion.
AMQP 0.9.1 and AMQP 1.0 are different protocols, not different versions of the same protocol. They have the same name for historical reasons, but they are incompatible on the wire, they define different things, and a client library written for one cannot talk to a broker that speaks only the other. When a piece of documentation says “AMQP,” you have to know which one it means.
Historically, the version that became widely deployed was AMQP 0.9.1, championed by RabbitMQ. When AMQP 1.0 was standardized by OASIS in 2012 (later becoming ISO/IEC 19464), the working group significantly restructured the protocol. The result was a genuine second protocol — no longer a message-queue protocol per se, but a generic peer-to-peer messaging protocol that does not even mandate the presence of a broker.
RabbitMQ, the most popular AMQP broker, defaulted to AMQP 0.9.1 for years. Only with the release of RabbitMQ 4.0 in 2024 did AMQP 1.0 become a core protocol alongside 0.9.1 rather than a plugin. Other brokers (Apache ActiveMQ, Azure Service Bus, IBM MQ, Solace, Apache Qpid) implement AMQP 1.0 as their primary AMQP interface.
Both are still very much in use today. Neither is being deprecated. When comparing to MQTT, both matter.
MQTT in one paragraph
MQTT is a lightweight publish/subscribe protocol designed for constrained devices and unreliable networks. Clients connect to a central broker, publish messages to topics, and subscribe to topics to receive messages. The broker fans messages out to every matching subscriber. Delivery guarantees are handled by three QoS levels (0, 1, 2) built into the protocol. The wire format is designed to be as small as possible: the minimum packet is two bytes. MQTT is covered in depth in the other articles in this category, especially the What Is MQTT flagship.
AMQP 0.9.1 in one paragraph
AMQP 0.9.1 is a message-queue protocol built around a specific server model: publishers send messages to exchanges, exchanges route to queues according to bindings and routing keys, and consumers read from queues. The protocol defines several exchange types (direct, topic, fanout, headers) with their own routing algorithms. Clients can programmatically declare exchanges, queues, and bindings on the broker, so client applications are aware of the server topology. This design is what made RabbitMQ powerful and flexible, and it is why AMQP 0.9.1 is still the default protocol most developers reach for when they choose RabbitMQ.
AMQP 1.0 in one paragraph
AMQP 1.0 is a peer-to-peer messaging protocol that defines only the wire protocol between two peers exchanging messages. It does not define a server model, does not require a central broker, and does not specify exchanges or queues. Instead, one node sends messages along a link to another node, with a source endpoint on one side and a target endpoint on the other, each identified by an address that the implementation resolves however it chooses. Nodes live inside containers, and a container can be a broker, a client application, or anything else that terminates AMQP. This makes AMQP 1.0 much more generic than 0.9.1: it can be layered on top of many different broker architectures, or even used without a broker at all, and it is the AMQP dialect used to connect heterogeneous messaging systems from different vendors.
Comparison by dimension
Rather than list features exhaustively, the useful comparison is dimension by dimension.
Complexity and learning curve
MQTT is the simplest of the three. The protocol has 15 control packet types (14 in MQTT 3.1.1), a small set of features, and a small conceptual footprint. A developer can be productive with MQTT in a day. There are no exchanges to declare, no bindings to configure, no routing algorithms to choose. You connect, publish, or subscribe.
AMQP 0.9.1 is more complex to learn but more powerful for routing. You need to understand exchanges, queues, bindings, exchange types, routing keys, and how the broker resolves each to route a message. A developer typically needs several days to become comfortable with the model. The payoff is that you can express routing patterns that would be awkward in MQTT.
AMQP 1.0 sits between them conceptually but is often the hardest to work with in practice, because the protocol leaves so much unspecified. Different brokers resolve addresses differently, and the code you write is often more broker-specific than the AMQP 1.0 spec would suggest.
Routing capabilities
MQTT uses topic-based routing with a hierarchical UTF-8 topic string separated by /. Wildcards + (single level) and # (multi-level) let a subscriber match multiple topics. This is enough for most cases but is fundamentally structural: routing is decided by the shape of the topic string.
AMQP 0.9.1 offers richer routing through exchange types:
- Direct exchange — match by exact routing key.
- Topic exchange — match by routing key pattern with wildcards (functionally similar to MQTT topics).
- Fanout exchange — broadcast to all bound queues, ignore routing key.
- Headers exchange — match by message headers rather than routing key.
Complex routing topologies (exchange-to-exchange bindings, custom exchange types via plugins) are possible in AMQP 0.9.1 in ways they are not in MQTT. This is one of AMQP 0.9.1’s real strengths.
AMQP 1.0 does not define routing at all; it defines how peers exchange messages along links. Routing decisions are made by whatever the target endpoint’s address resolves to in the specific broker, which means routing capabilities depend on the broker rather than the protocol.
Delivery guarantees
MQTT has three Quality of Service levels (0 at-most-once, 1 at-least-once, 2 exactly-once), negotiated per hop between publisher-and-broker and broker-and-subscriber. QoS is a per-message and per-subscription decision.
AMQP 0.9.1 provides similar guarantees through publisher confirms (broker acknowledges when the message is safely stored) and consumer acknowledgements (consumer explicitly acks after processing). It has more knobs (transaction support, negative acknowledgements, requeue behavior) than MQTT.
AMQP 1.0 has an even richer delivery-state model with formal outcomes: accepted, rejected, released, modified. Both sides negotiate settlement mode for each message, giving fine control over when acknowledgement happens. AMQP 1.0’s delivery model is the most sophisticated of the three, and for scenarios where reliability semantics are complex (financial messaging, for example), this is often decisive.
Message size and overhead
MQTT is the most compact. The minimum fixed header is 2 bytes; a typical small publish is only slightly larger. This is why MQTT is the choice for constrained devices and low-bandwidth links.
AMQP 0.9.1 has larger frames (a method frame, a header frame, and one or more body frames per message), and its methods and properties are richer than MQTT’s. In absolute terms this is often measured in tens of bytes per message rather than the two of MQTT, which is significant on constrained links.
AMQP 1.0 frames are also larger than MQTT, with performatives and typed descriptors adding overhead. AMQP 1.0’s design prioritizes flexibility and expressiveness over compactness.
Scale and connection density
All three protocols scale, but their sweet spots differ.
MQTT brokers, particularly EMQX and HiveMQ Enterprise, routinely handle millions of concurrent connections per broker. The lightweight connection model was designed for exactly this: many long-lived connections from constrained clients. See the Open Source MQTT Broker article for scale figures.
AMQP 0.9.1 brokers like RabbitMQ handle hundreds of thousands of connections per node, though this often requires tuning. RabbitMQ is not typically deployed at the same connection density as MQTT brokers; it is more commonly deployed for high throughput and complex routing with a smaller number of well-known clients.
AMQP 1.0 connection density depends entirely on the broker. Some brokers built for AMQP 1.0 (like Azure Service Bus) scale enormously; others are more modest.
Constrained devices
MQTT is the clear winner on this axis. A minimal MQTT client library fits in a few kilobytes and runs on microcontrollers with tens of kilobytes of RAM. The protocol was designed for these environments from the start.
AMQP 0.9.1 clients are heavier. There are AMQP 0.9.1 libraries for many languages, but they are not designed for embedded devices; they typically require more memory, more code, and more concept-mapping than an embedded developer wants to deal with.
AMQP 1.0 clients are lighter than 0.9.1 in some implementations, but still not competitive with MQTT for embedded use. AMQP 1.0’s flexibility comes with library complexity.
Interoperability across vendors
MQTT clients from any vendor talk to MQTT brokers from any vendor. The protocol is small enough that everyone implements it consistently. Multi-vendor deployments (a Mosquitto broker plus an EMQX cluster plus an HiveMQ server) can bridge to each other and share clients.
AMQP 0.9.1 interoperability is largely a RabbitMQ story. Other brokers implement AMQP 0.9.1 to varying degrees, but RabbitMQ is the de facto reference implementation.
AMQP 1.0 is where interoperability was the explicit design goal. A single AMQP 1.0 client library can talk to Azure Service Bus, IBM MQ, Apache ActiveMQ, Solace, and RabbitMQ 4.0+. This is one of AMQP 1.0’s genuine strengths: for organizations that need to talk to multiple different broker vendors from one client codebase, it is the right choice.
Ecosystem and community
MQTT has an enormous, IoT-dominated ecosystem. Brokers (Mosquitto, EMQX, HiveMQ, and many others), client libraries in every language, tooling for testing and management, and vast community support. If you have an IoT problem, most of the tooling assumes MQTT.
AMQP 0.9.1 is essentially the RabbitMQ ecosystem, which is very large in its own right. RabbitMQ is one of the most widely-deployed open source message brokers in the world, with client libraries in most languages and heavy adoption in enterprise environments.
AMQP 1.0 has a smaller but growing ecosystem, concentrated around enterprise vendors: Azure Service Bus, IBM MQ, Apache ActiveMQ, Solace, Red Hat AMQ, and Apache Qpid. Client library availability varies more by language than MQTT or AMQP 0.9.1.
Standardization
MQTT is an OASIS Standard (3.1.1 in 2014, 5.0 in 2019).
AMQP 0.9.1 is not an OASIS standard. It is an informal specification maintained outside the OASIS process. This surprises many developers, because it is so widely deployed.
AMQP 1.0 is both an OASIS Standard (2012) and an ISO/IEC standard (19464). It is the “official” AMQP in the standards sense.
When MQTT is the right choice
Some situations point cleanly to MQTT.
IoT and device telemetry. This is what MQTT was designed for. Small payloads, many devices, unreliable networks, bidirectional communication, delivery guarantees when needed. MQTT is the default choice for this shape of use case, and the protocol’s IoT-tailored features (Last Will and Testament, retained messages, persistent sessions with per-QoS queuing) all serve it.
Constrained devices. Microcontrollers, battery-powered sensors, embedded systems. The small footprint of MQTT clients is often the deciding factor. AMQP libraries are not competitive here.
Very high connection counts. Fleet-scale deployments with millions of concurrent clients. MQTT brokers at this scale exist as commodities; AMQP brokers at this scale exist but are less common.
Simple messaging semantics. Publish/subscribe, topics, wildcards, and QoS. If your use case fits this, MQTT is enough, and adding AMQP complexity buys you nothing.
Cross-vendor MQTT broker deployments. If you want to run different brokers in different environments (Mosquitto at the edge, EMQX in the cloud, HiveMQ for enterprise), MQTT interoperability is excellent.
When AMQP 0.9.1 is the right choice
Some situations point to AMQP 0.9.1 specifically.
RabbitMQ deployments. If you are running RabbitMQ, AMQP 0.9.1 is its native language and the most mature interface. Even RabbitMQ 4.0 with core AMQP 1.0 support does not obsolete 0.9.1; RabbitMQ’s own ecosystem, tooling, and documentation are still heavily 0.9.1-oriented.
Complex routing with exchange types. If your messaging pattern needs the routing sophistication of exchanges (headers exchanges, custom exchange types, complex bindings), AMQP 0.9.1’s server model gives you these first-class. Simulating them in MQTT is possible but awkward.
Enterprise message-queue workloads. Traditional work-queue patterns (one producer, N consumers competing for messages, dead letter queues, priority queues) are a natural fit for AMQP 0.9.1’s model. MQTT’s shared subscriptions (in MQTT 5) address some of this, but AMQP 0.9.1 has been doing it for much longer.
Existing ecosystem. Client libraries, tooling, examples, and community knowledge — if your team already knows RabbitMQ / AMQP 0.9.1, that is a real asset. Do not throw it away without cause.
When AMQP 1.0 is the right choice
Some situations specifically point to AMQP 1.0.
Cross-vendor interoperability. If you need to talk to multiple heterogeneous message-broker vendors from one client codebase, AMQP 1.0 is what it was designed for. Azure Service Bus, IBM MQ, ActiveMQ, Solace, and modern RabbitMQ all speak it.
Standards-mandated environments. Some industries and organizations require ISO or OASIS standardized protocols. AMQP 1.0 is both; AMQP 0.9.1 is neither. In practice this constraint is rare, but when it applies, AMQP 1.0 is often the answer.
Sophisticated delivery-state semantics. For messaging patterns where the acceptance / rejection / release / modification of individual messages needs fine-grained control, AMQP 1.0’s delivery-state model is the most expressive of the three protocols.
Cloud-native enterprise messaging on managed services. Azure Service Bus, in particular, exposes AMQP 1.0 as its native protocol. If your architecture is deeply on Azure, AMQP 1.0 is the natural choice.
The mental model: how each protocol moves a message
Because the three protocols have such different models, it helps to picture how a single message actually flows through each.
In MQTT, a client sends a PUBLISH to the broker on a specific topic. The broker matches the topic against all active subscriptions and forwards a copy of the message to each subscribing client whose topic filter matches. That is the whole flow: publisher → broker → subscribers. There is no intermediate structure to configure. The publisher does not know how many subscribers received the message, or whether any did. Topics are created on the fly by simply publishing to them.
In AMQP 0.9.1, a publisher sends a message to an exchange, tagged with a routing key. The exchange consults its bindings (rules that connect it to queues) and, using its exchange type (direct, topic, fanout, or headers), decides which queues to copy the message to. The message then sits in those queues until a consumer subscribed to each queue reads it. Consumers explicitly acknowledge messages; unacknowledged messages can be requeued. So the flow is publisher → exchange → bindings → queues → consumers. Every stop along the way is a first-class concept, and clients typically declare exchanges, queues, and bindings themselves. The routing power comes from the exchange types and the flexibility of bindings.
In AMQP 1.0, one peer transfers a message along a link from a source endpoint to a target endpoint on another peer. Each endpoint has an address, and what those addresses mean is entirely up to the implementation. In a broker like RabbitMQ 4.0, an AMQP 1.0 target address might refer to an AMQP 0.9.1 exchange; in Azure Service Bus, it refers to a Service Bus queue or topic; in another broker, it might refer to a stream or an in-memory data structure. The protocol handles the wire-level exchange of messages, delivery states, and settlement, but the routing model is outside the spec. This is why the same AMQP 1.0 client library can talk to very different brokers: the wire protocol is the same even when the underlying model is not.
The three mental models are not equivalent. MQTT gives you fan-out with almost no configuration. AMQP 0.9.1 gives you rich broker-managed routing with explicit setup. AMQP 1.0 gives you a portable wire protocol on top of whatever routing the broker chooses to expose. Which of these fits your system depends less on the raw features and more on how you want to think about the messaging layer.
Can you use both?
Yes, and some architectures do. It is not unusual to see MQTT at the edge (for device connectivity) and AMQP within the backend (for enterprise integration), with a gateway translating between them. RabbitMQ, for example, supports both MQTT and AMQP 0.9.1 natively and can bridge messages between them. Some cloud IoT platforms accept MQTT from devices and expose AMQP to backend systems.
If you have a mixed environment, the choice is not either/or. It is about which protocol serves which layer well, with a translation point in between if needed.
Common misconceptions
A few things people believe that are not quite right.
“AMQP is a newer version of MQTT.” No. They are completely different protocols from different origins. MQTT was created in 1999 by IBM; AMQP 0.9.1 emerged from JPMorgan Chase in the mid-2000s; AMQP 1.0 was standardized in 2012. Neither is a “version” of the other.
“AMQP 1.0 replaces AMQP 0.9.1.” No. Despite OASIS calling AMQP 0.9.1 “legacy,” new AMQP 0.9.1 client libraries and even new AMQP 0.9.1 brokers (LavinMQ, for example) continue to be built. AMQP 0.9.1’s simplicity and the strength of the RabbitMQ ecosystem keep it very much alive.
“MQTT is only for IoT; AMQP is for enterprise.” Not quite. MQTT is used in enterprise messaging (financial services, chat platforms, real-time dashboards); AMQP 0.9.1 is used outside enterprise (background job queues, application messaging). The use case matters more than the label.
“AMQP is faster than MQTT.” Depends on what you measure. MQTT has lower per-message overhead, which usually makes it faster for many small messages. AMQP has richer routing that can move work from clients to broker, which can be faster for complex routing scenarios. Neither is universally faster.
“MQTT does not have delivery guarantees.” MQTT has three QoS levels, one of which (QoS 2) is exactly-once at the protocol level. What MQTT does not have is a rich delivery-state model like AMQP 1.0’s, but it does have delivery guarantees.
Frequently asked questions
What is the main difference between MQTT and AMQP? MQTT is a lightweight publish/subscribe protocol designed for IoT and constrained devices; AMQP is a messaging protocol with two very different specifications (AMQP 0.9.1 and AMQP 1.0). AMQP 0.9.1 defines a server model with exchanges and queues; AMQP 1.0 defines only the wire protocol between peers. MQTT is simpler and lighter; AMQP is more feature-rich and offers more sophisticated routing and delivery semantics.
Is AMQP better than MQTT? Neither is universally better. MQTT wins for IoT, constrained devices, and simple publish/subscribe messaging. AMQP 0.9.1 wins for complex routing (especially on RabbitMQ). AMQP 1.0 wins for cross-vendor enterprise messaging and sophisticated delivery semantics.
Are AMQP 0.9.1 and AMQP 1.0 the same protocol? No. They are different protocols that share a name. They are not wire-compatible, they define different things (0.9.1 defines a server model; 1.0 does not), and a client for one cannot talk to a broker for the other.
Which is faster, MQTT or AMQP? For small, frequent messages, MQTT has lower per-message overhead and typically feels faster. For complex routing scenarios where AMQP can move work from the client to the broker, AMQP can be more efficient overall. Neither is universally faster.
Can I use MQTT and AMQP together? Yes. Many architectures use MQTT at the edge (for device connectivity) and AMQP within the backend (for enterprise integration), with a gateway or a broker like RabbitMQ (which supports both) bridging between them.
Does RabbitMQ support MQTT? Yes. RabbitMQ supports both MQTT and AMQP 0.9.1 (its native protocol) and, since version 4.0, AMQP 1.0 as a core protocol. Messages can be bridged between the two protocol worlds within the same broker.
Is AMQP 1.0 an ISO standard? Yes. AMQP 1.0 is ISO/IEC 19464 and an OASIS Standard. AMQP 0.9.1 is not.
Which protocol should I use for IoT? MQTT is the default recommendation for IoT: small payloads, unreliable networks, constrained devices, and bidirectional communication are exactly what it was designed for. Some IoT deployments use AMQP for backend integration, but MQTT is nearly always the device-facing protocol.
Which protocol should I use for enterprise messaging? AMQP 0.9.1 with RabbitMQ is a common choice for complex routing patterns; AMQP 1.0 is the choice when interoperating with multiple message-broker vendors, or when using managed services like Azure Service Bus. MQTT is used in enterprise for scenarios that align with its strengths (publish/subscribe, high connection counts).
Do MQTT and AMQP support TLS? Yes, all three protocols support TLS for transport security, and it is the recommended default for anything beyond local testing. All three also support SASL for authentication, though the specifics vary by broker.