When to Use AMQP, JMS, Kafka, or MQTT: Trade-offs, Not a Winner

AMQP, JMS, Kafka, and MQTT get lined up as if you pick one and move on. Most of the time that comparison is a category error.

That error is getting easier to make, because the tools now overlap more than they used to. Kafka added queue semantics with Share Groups. RabbitMQ added a log. AMQP’s standards committee reconvened after years of quiet, now around agentic AI. MQTT settled into version 5.0 as the default at the edge. JMS, the mature exception, sits still because it already works. The tools are borrowing each other’s features. The models underneath, and the trade-offs that come with them, have not merged.

So the useful question is not which one wins. It is which one fits, given what you already run and what the workload actually needs. This post covers what each one is, how they differ, when to use which, and why a single platform often speaks several at once.

What are AMQP, JMS, Kafka, and MQTT?

Four short definitions before the comparison, since half the confusion comes from mixing up what each one actually is.

What is AMQP?

AMQP (Advanced Message Queuing Protocol) is a wire-level protocol for reliable messaging between business applications. It defines the bytes on the network, not a programming interface, so any compliant client can talk to any compliant broker regardless of language.

It is an OASIS standard and ISO/IEC 19464, originally created at JPMorgan to standardize financial messaging. One point trips up nearly every comparison: AMQP 0.9.1 and AMQP 1.0 are different, wire-incompatible protocols. Classic RabbitMQ made 0.9.1 ubiquitous, while enterprise brokers like Azure Service Bus and IBM MQ use 1.0. RabbitMQ has supported 1.0 natively since version 4.0.

What is JMS?

JMS (Java Message Service, now Jakarta Messaging) is a Java API, not a wire protocol. It standardizes how Java code sends and receives messages, not the bytes that travel between systems, so the transport underneath is the provider’s to decide. That is why JMS can run over AMQP or a vendor’s own protocol without the application noticing.

JMS is mature and stable rather than fast-moving, and it remains the default messaging abstraction across large Java and Jakarta EE environments. In theory that means you can swap one JMS provider for another, but in practice vendors like IBM and Oracle add proprietary extensions and each ships its own wire protocol underneath, so replacing a provider is a migration, not a drop-in switch.

What is Kafka?

Apache Kafka is a distributed platform built around a durable, append-only commit log. Producers append events, and many consumers read at their own pace by tracking offsets, so data is retained and replayable rather than deleted on consumption. Because events are stored rather than removed on consumption, producers and consumers are fully decoupled in time: a consumer can join later, replay history, or fall behind and catch up, and new consumers can read the same events without the producer knowing.

A traditional message broker works differently, deleting a message once it is delivered, which couples the two sides in time. Kafka is the de facto standard for event streaming, governed by the Apache project rather than a formal standards body. It scales to very high throughput and, with Queues for Kafka (QfK), now supports queue-style consumption as well.

What is MQTT?

MQTT, which began as MQ Telemetry Transport, is a lightweight publish/subscribe wire protocol for constrained devices and unreliable networks. It is an OASIS standard and ISO/IEC 20922. Its design center is IoT and edge telemetry: small footprint, low bandwidth, many connections. Version 5.0 added shared subscriptions, richer metadata, and better error reporting.

How AMQP, JMS, Kafka, and MQTT actually differ

AMQP, JMS, Kafka, and MQTT appear in the same sentence constantly, but they do not sit on the same axis. One is an API. Two are general messaging protocols with different models. One is a device protocol. Treating them as rivals hides the distinctions that matter.

Each comparison below pairs AMQP with one of the others, because AMQP is the general-purpose enterprise messaging wire protocol and each of the rest diverges from it on a different axis. Each starts with the category error, then the useful distinction, then when to reach for which.

AMQP vs JMS: API or wire protocol?

The category error is treating them as rival messaging systems. They are not on the same layer. JMS is a Java API. AMQP is a language-neutral wire protocol. You can even run JMS over AMQP: Apache Qpid JMS implements the JMS API on top of the AMQP 1.0 wire.

The useful distinction is where each stops. JMS abstracts messaging for Java code but leaves the transport to whichever provider you plug in, so portability ends at the API boundary. AMQP standardizes the transport itself, so a Python producer and a Java consumer interoperate through any compliant broker.

When to reach for which: choose JMS when you live in a Java or Jakarta EE world and want a portable API across providers. Choose AMQP when you need cross-language interoperability or want to decouple from a single vendor’s wire protocol. They also combine, and a JMS front end over an AMQP transport is a common enterprise pattern.

AMQP vs Kafka: queue or log?

The category error is assuming two binary wire protocols must be interchangeable. They share a shape and little else. AMQP message brokers deliver a message to a consumer and remove it, with flexible routing and per-message handling. Kafka keeps an ordered, durable log that consumers read by offset, so the same events can be replayed and read by many independent consumers. Governance differs too. AMQP is a formal ISO standard. Kafka is a de facto standard defined by the Apache project’s implementation, which is why compatible engines like Redpanda, WarpStream, and Confluent’s Kora reimplement the same protocol rather than a frozen spec.

The name Queues for Kafka (QfK) confuses people. It sounds like Kafka became a message broker. It did not. QfK introduces Share Groups, where each message goes to exactly one consumer, adding queue-style consumption on top of the same log. It is queue semantics layered on Kafka, not a separate queue engine, and it does not make Kafka speak AMQP or replace a broker’s routing and transactions. For when it fits and when it does not, see When (Not) to Use Queues for Kafka.

The wider point is that a message broker and a data streaming platform solve different problems and often run side by side, one for point-to-point messaging and one as the central data hub. For the full breakdown, see JMS Message Queue vs. Apache Kafka.

One caveat applies to all four, not just Kafka: strengths tell you where a tool shines, not the only place it belongs. Kafka is the clearest example. Thousands of companies run it as the durable backbone for data integration and operational messaging, often well under a thousand messages per second, and that is a first-class use, not a compromise. The reason is the core, not the throughput: a replicated, persistent log with failover and 24/7 availability, decoupling producers from consumers whether the volume is huge or small. The real trade-off is operational weight. You take on running a distributed platform, so you choose Kafka for that durable, always-on backbone and its ecosystem, not to avoid standing up a simple queue. The logic runs both ways. If IBM MQ already anchors your transactional backends with XA and mainframe integration, that is not something you replace for fashion.

When to reach for which: AMQP for reliable application-to-application messaging, request-reply, complex routing, and transactions. Kafka for streaming, event sourcing, and replay, and equally as a durable, always-on backbone for data integration and operational messaging at any volume.

AMQP vs MQTT: enterprise core or edge?

The category error is smaller here, because both are open wire protocols and both are OASIS and ISO standards, so people assume they compete across the board. They rarely do. The difference is design center. MQTT is deliberately lightweight, tuned for constrained devices, telemetry, and lossy networks, with tens of thousands of connections. AMQP carries richer enterprise semantics and heavier per-message guarantees.

In practice AMQP and MQTT are complementary. MQTT collects data at the edge, and AMQP or another broker carries it through the enterprise core. That is why the cross-membership between the AMQP and MQTT committees matters. Many environments run both, and alignment helps the architects who combine them. MQTT and Kafka pair the same way in IoT: MQTT moves data off constrained devices over unreliable networks, and Kafka processes and integrates it at scale in the core, rather than one replacing the other. For real-world end-to-end examples and case studies, see the blog series Apache Kafka, MQTT, and Sparkplug for IoT.

When to reach for which: MQTT for IoT, device fan-in, and the edge over unreliable links. AMQP for the enterprise messaging tier behind it.

AMQP vs JMS vs Kafka vs MQTT: comparison table

The row “delivery guarantee” deserves a warning, because “exactly once” is the most misunderstood term in this space. The phrase means something different in each system. Kafka’s exactly-once semantics apply within Kafka, through idempotent producers and transactions. MQTT QoS 2 guarantees exactly-once delivery on a single hop between client and broker. AMQP settlement modes give at-most-once and at-least-once, with exactly-once left to application-level deduplication. JMS depends on acknowledgment mode and XA transactions. None of them hands you free end-to-end exactly-once across heterogeneous systems. When a vendor claims exactly-once, ask exactly once where.

When should you use AMQP, JMS, Kafka, or MQTT?

The trade-offs collapse into a short set of scenarios. Read them as starting points, not fences: a tool’s strengths tell you where it shines, not the only place it belongs. Weigh each against what you already run and what your team knows.

Use these scenarios as a quick guide to which protocol fits:

• You need reliable application-to-application messaging across languages, with routing, request-reply, or transactions: AMQP, via RabbitMQ, Azure Service Bus, IBM MQ, Solace, or ActiveMQ Artemis.
• You have a Java or Jakarta EE environment and want a portable messaging API: JMS, over whichever provider fits.
• You need streaming, event sourcing, replay, high-volume pipelines, or analytics ingestion into a lake, warehouse, or lakehouse: Kafka.
• You want one strategic platform in the enterprise architecture across use cases rather than a tool per problem: Kafka as the integration backbone for streaming, durable operational messaging, and data integration. A deliberate architectural bet that pays off when the same governed events feed many consumers, and how large enterprises have consolidated multiple MQ, ETL, ESB, and iPaaS middleware onto one Kafka platform for years.
• You are connecting devices at the edge over unreliable networks, both collecting telemetry and sending commands or control back to them: MQTT, bridged to a core broker or streaming platform.
• You already run an established messaging platform like IBM MQ or TIBCO for transactional backends that work: start by integrating, not replacing, for example with a Kafka connector for IBM MQ, then retire pieces gradually with the strangler fig approach if a move makes sense, rather than a rip and replace.

The pattern across all of these is that the question is rarely which protocol wins. It is which model fits the workload, and most real enterprise architectures run more than one.

Why one platform supports several messaging protocols

Vendors support multiple protocols for one reason above all: to meet customers where they already are. Enterprises rarely start clean. They have Java applications expecting JMS, devices speaking MQTT, teams standardized on Kafka, and legacy systems wired to a specific broker. A platform that speaks several protocols lets those teams connect without rewriting clients, eases migration away from an incumbent, and removes the lock-in objection that stalls deals. It also lets one vendor serve more of the customer’s systems instead of ceding the streaming half to Kafka or the edge half to an MQTT broker. The commercial incentive and the architectural one point the same way: cover more workloads, lose fewer of them.

There are two ways vendors deliver this, and they work differently.

Multi-protocol brokers: breadth over depth

Multi-protocol brokers translate to a shared model. RabbitMQ maps AMQP 0.9.1, AMQP 1.0, MQTT, STOMP, and Streams onto one internal model, so you can publish over one protocol and consume over another. Solace does the same across JMS, AMQP, MQTT, REST, and WebSocket. The mechanism is protocol conversion against a single broker model. The trade-off to name is depth. Conversion tends to expose a lowest-common-denominator subset, so a client using AMQP through a broker built for something else may not get every native AMQP feature.

Separate products: depth over breadth

Separate products under one umbrella is the other pattern. Azure is the clean example. Service Bus handles AMQP enterprise messaging. Event Hubs exposes a Kafka-compatible endpoint for streaming. Two purpose-built services, not one broker translating, with bridges connecting the systems. The reason to split rather than unify is the same one that runs through this whole article: the models differ enough that one engine optimized for all of them ends up mediocre at each. A log tuned for replay and a queue tuned for per-message routing pull hardware and design in opposite directions.

Why agentic AI is reviving AMQP

AMQP has been in production for years. Agentic AI is now adding new use cases for it, because the Model Context Protocol (MCP) standardizes how agents call tools but not how those calls are delivered reliably.

What is MCP, and why does it need messaging?

Anthropic introduced MCP in late 2024 as an open standard for connecting AI agents to external tools and data. Before it, every model needed a custom connector to every system, so three models and ten systems meant thirty integrations to build and maintain. MCP collapses that to one interface: any compliant agent talks to any compliant tool. Adoption moved fast across the major data platform, integration, and AI vendors, and it is now a default way agents reach external capabilities.

MCP is an interface layer, not a transport guarantee. It standardizes how a tool is called. It does not manage data, guarantee delivery, or enforce consistency. Most MCP deployments run request-response over HTTP, which is fine when a tool call is supplementary and a slightly stale answer is acceptable.

Messaging enters where that model strains. Agents that call tools, wait on results, and coordinate across steps sometimes need more than a synchronous HTTP call: reliable, ordered, transactional delivery, buffering when a downstream service is slow, and durability when something fails midway. A messaging protocol provides exactly that, where a bare HTTP request does not. It is the same reason enterprises put a broker or a streaming platform between systems instead of wiring everything point to point. For the deeper comparison of MCP, HTTP, and Kafka as integration options, see MCP vs REST/HTTP API vs Kafka.

MCP over AMQP

This is where AMQP re-enters. The AWS Amazon MQ team published an open-source MCP-over-AMQP transport that runs MCP over both AMQP 0.9.1 and AMQP 1.0, letting the broker handle guaranteed delivery, retries, and dead-letter queues. The OASIS AMQP committee reconvened in 2026, now with RabbitMQ (Broadcom), IBM MQ, and the AWS Amazon MQ team among the participants, and a shared MCP-over-AMQP profile is one of the topics on the table. A standard that predates the current AI wave is getting attention again because agents need the properties it was built for.

The transport is only half the picture. Agents are only as reliable as the data they act on, and MCP does not make data current or consistent on its own. That job belongs to the layer beneath it, where a messaging or streaming platform delivers governed, up-to-date context to the agent. For the deeper architecture, see operational, analytical, and AI interfaces for real-time data products.

Interoperability is the second reason AMQP suits agentic systems. If agents span vendors and clouds, the transport beneath them is better off as a neutral standard than as one product’s protocol.

There is no winner, only fit for the workload

The four are not competitors on one list; they are different tools that increasingly show up in the same architecture. AMQP is not new. JMS is older. Kafka and MQTT are both well past a decade. What changed is that all four are evolving at once.

The temptation to crown one grows with every borrowed feature. Resist it. There is no winner here, only fit. Match the model to the workload, respect what you already run, and combine protocols where the strengths are complementary. The question worth asking is not which of these survives. It is how well they work together.