- Message queues side by side
- Eleven message queues and brokers
- Where to start for your system
- Why an open messaging standard helps later
- Message queues versus event streaming
- Questions to ask before you choose a message queue
- Signs your system needs a message queue
- My plain advice on choosing a message queue
- Frequently asked questions
The best message queues let one part of your system hand work to another reliably, even when the receiving service is busy or briefly down. Some are open source brokers you run yourself, while others are managed cloud services or serverless queues you call over HTTP. Eleven options follow in no particular order.
When one service calls another directly, a slow or failed service drags everything down with it. A message queue sits in between. The sender drops a message and carries on, and the receiver picks it up when it's ready, so a spike in orders or a brief outage doesn't turn into lost work.
The eleven message queues below are listed alphabetically and in no particular order, and every description comes from the project's or provider's own website, read this week. If you're still deciding how to split your application up, my guide to monoliths versus microservices covers that choice.
Message queues side by side
I checked the free plan column on each tool's own website, as of Oct 2026. Yes means the site names a free plan, a free version, a free allowance or an open source version. Trial only means a time-limited trial. Not stated means the pages I read named neither, even where there's a button inviting you to start for free, so check the vendor's page before you rely on it.
| Tool | Type | Good for | Free plan |
|---|---|---|---|
| ActiveMQ | Open source multi-protocol message broker | Java shops needing several protocols | Yes |
| Amazon SQS | Fully managed message queuing on AWS | Serverless apps on AWS | Yes |
| Apache Kafka | Open source distributed event streaming platform | High-throughput event streams | Yes |
| Apache Pulsar | Open source messaging and streaming platform | Queues and streams in one system | Yes |
| Azure Service Bus | Cloud messaging service on Microsoft Azure | Enterprise apps on Azure | Not stated |
| CloudAMQP | Managed message broker hosting | A familiar broker without running servers | Not stated |
| IronMQ | Serverless message queue | A hosted queue with no infrastructure | Trial only |
| NATS | Cloud-native, open source messaging system | Lightweight messaging at the edge | Yes |
| RabbitMQ | Open source messaging and streaming broker | A general-purpose broker most teams know | Yes |
| Upstash QStash | Serverless messaging and scheduling | Scheduled jobs in serverless apps | Not stated |
| ZeroMQ | Open source universal messaging library | Building messaging into your own code | Yes |
Eleven message queues and brokers
ActiveMQ
Best for: Java teams who want a popular open source, multi-protocol message broker they can run themselves, from the Apache Software Foundation.
Amazon SQS
Best for: Teams building on AWS who want fully managed message queues for microservices, distributed systems and serverless apps, with an AWS free tier.
Apache Kafka
Best for: Engineering teams who need an open source distributed event streaming platform for very large volumes of data, with a huge ecosystem.
Apache Pulsar
Best for: Platform teams who want one open source, cloud-native system for both messaging and streaming rather than running two separate tools.
Azure Service Bus
Best for: Organisations on Microsoft Azure that want a managed cloud messaging service for connecting enterprise applications and services.
CloudAMQP
Best for: Teams who'd rather not run their own broker and want a managed message broker service with round-the-clock human support.
IronMQ
Best for: Developers who want a serverless message queue from a cloud-native provider, with a free trial before they move workloads across.
NATS
Best for: Engineers building distributed systems who want a lightweight, high-performance, open source messaging system that runs anywhere.
RabbitMQ
Best for: Most teams starting out with queues, who want free and open source software with commercial support available if they need it later.
Upstash QStash
Best for: Serverless and edge developers who want messaging and scheduling without a broker, such as a daily job that cleans up a database.
ZeroMQ
Best for: Developers who want an open source messaging library inside their own code rather than a separate broker to deploy and manage.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Where to start for your system
- A general-purpose broker most teams know: RabbitMQ.
- High-throughput event streams: Apache Kafka.
- Queues and streams in one system: Apache Pulsar.
- Lightweight messaging that runs anywhere: NATS.
- Java shops needing several protocols: ActiveMQ.
- A managed queue on a big cloud: Amazon SQS or Azure Service Bus.
- A managed broker without running servers: CloudAMQP or IronMQ.
- Serverless jobs and schedules: Upstash QStash.
- Messaging inside your own code: ZeroMQ.
Why an open messaging standard helps later
The AMQP website says the Advanced Message Queuing Protocol 1.0 became an OASIS Standard and is also published as the International Standard ISO/IEC 19464.
Standards like that matter when you want to switch brokers or connect systems written in different languages. A broker that speaks an open protocol is easier to replace, and client libraries are usually easy to find.
Message queues versus event streaming
A message queue hands each message to a consumer, which processes it and removes it. It's ideal for background jobs, order processing and anything that should happen once.
An event streaming platform keeps a log of events that many consumers can read, replay and process at their own pace. It suits analytics, audit trails and systems where several services react to the same event.
Questions to ask before you choose a message queue
- Do we need simple queues, event streams or both?
- Will we run it ourselves or use a managed service?
- What happens to a message if a consumer fails?
- Can it handle our peak volume?
- Which protocols and client libraries do we need?
- How will we monitor queue depth and delays?
Signs your system needs a message queue
- One slow service drags others down. Decouple them.
- Traffic spikes cause lost work. Buffer requests in a queue.
- Background jobs block the user. Move them to a worker.
- Several services need the same event. Publish it once.
Do you make a message queue, broker or event streaming service? Tool makers can ask to be considered for a featured place on this list.
My plain advice on choosing a message queue
Choose the simplest option that meets your needs today. A managed queue from your cloud provider or a familiar open source broker covers most applications, and you can add event streaming later if you need replay and many consumers.
Whatever you pick, make your consumers safe to run twice, because retries happen. And keep your integrations tidy, as my explainer on what an API is shows how the pieces fit together.
Frequently asked questions
What is a message queue?
A message queue lets one service send messages that another service processes later, so work isn't lost when a service is busy or down.
What's the difference between a message queue and event streaming?
A queue hands each message to one consumer, while event streaming keeps a log that many consumers can read and replay.
Are there free message queues?
Yes. Several are open source, and some cloud services include free tiers. The free plan column above shows what each site says.
What is AMQP?
AMQP is the Advanced Message Queuing Protocol, an open standard for passing messages between applications.
Should I run my own broker or use a managed service?
A managed service saves operations work, while running your own gives more control. Small teams usually start managed.
Can a message be delivered twice?
It can happen with retries, so design consumers so that processing the same message twice does no harm.
