Which open-source message broker fits your situation
If your team must self-host a broker for durable event streaming, task queues or mixed protocols, start with the workload, not the brand. Kafka fits durable event logs and the Kafka ecosystem, where consumers replay history and connectors such as Kafka Connect move data to and from other systems. Kafka is Apache-2.0 licensed and the project itself offers no paid edition, so your costs are the infrastructure, the operating staff and any outside support you buy. RabbitMQ is a better fit when routing, work queues and protocol breadth matter more than replay, since it was built around AMQP 0-9-1 and adds AMQP 1.0, MQTT and STOMP through its plugin model. Its server and core plugins are MPL 2.0, and Broadcom offers commercial lifecycle support beyond community dates.
Pulsar fits multi-tenant streaming where storage should scale apart from brokers. Its architecture separates stateless brokers from BookKeeper bookies, so you add storage capacity by adding bookies, and it supports multi-tenancy, quotas and geo-replication. Pulsar is Apache-2.0 licensed. Before you commit, check its release calendar: the researched facts show Pulsar 4.0 LTS active support ending October 21, 2026, and confirm which LTS line your platform team will standardize on. Redpanda is a Kafka-compatible option, but it is source-available rather than Apache-2.0, so have legal review its license terms against your redistribution and hosting needs before you treat it as an alternative to Kafka.
Make the decision with three checks: which protocols your producers and consumers already speak, whether you need replay from a retained log, and who will operate the metadata and storage layers. Kafka 4.0 and later run only in KRaft mode, so ZooKeeper-based clusters must migrate first, and Pulsar requires you to choose a metadata store. Ask each vendor or project for its current support window and upgrade path in writing, and confirm them against your own environment before you size the platform.
Which broker suits which scenario
This table maps five common broker scenarios to the option that fits best and the condition under which each choice stops making sense. Read each row against your own workload, team skills and operating model before shortlisting. The main takeaway is that replay, routing, tenancy, protocol reach and existing client investment should decide the choice more than raw throughput claims.
| Scenario | Best fit | Why, and when it does not win |
|---|---|---|
| Event sourcing and replay | Apache Kafka | Retained, replayable logs and consumer offsets suit event-driven state rebuilds. It is a weaker fit if you need per-message routing rules or broker-side acknowledgement workflows more than long retention. |
| Work queues with per-message routing | RabbitMQ | Exchanges, bindings and per-message acknowledgement fit task distribution well. It is a weaker fit for very long message retention or replaying history for many independent consumers. |
| Multi-tenant platforms | Apache Pulsar | Built-in multi-tenancy, quotas and separation of compute from BookKeeper storage suit shared platforms. It adds operating components (brokers, bookies, metadata store) that a small team may find heavy to run. |
| IoT or mixed protocol gateways | RabbitMQ (with plugins) | MQTT, STOMP and AMQP 1.0 are reachable on one broker through plugins, which helps mixed device and application traffic. Confirm protocol coverage and plugin support against your device profile, and consider a dedicated MQTT broker for large device fleets. |
| Teams already on Kafka clients | Apache Kafka | Existing producers, consumers and Kafka Connect investment carry over directly. It is a weaker fit if clients need only queue semantics, since reusing Kafka then adds operating cost without a matching benefit. Confirm client library versions and Java 17 broker requirements before upgrading. |
How the messaging models differ in practice
Kafka, RabbitMQ and Pulsar all move messages, but they differ in what they treat as the primary record. Kafka writes events to an append-only log that consumers read by offset, so a consumer can rewind and replay history without the broker deleting it on delivery. That makes Kafka the stronger fit when several independent systems need the same event stream, when you need to reprocess data after a bug fix, or when event history is itself a product. Kafka 4.x runs only in KRaft mode, so a new cluster has no ZooKeeper to operate, but ZooKeeper-based clusters must migrate before upgrading, which is a planning item if you inherited an older deployment. Confirm the Java 17 requirement for brokers and Connect with your platform team before sizing hosts.
RabbitMQ uses a different model. Producers publish to exchanges, bindings route messages to queues, and consumers acknowledge each message so the broker can remove it. Routing rules, per-message acknowledgment, dead-letter handling and request-style work distribution are its strengths, and they matter most when routing logic is complex or when a task must be done once by one worker. Quorum queues, which use Raft replication, are the default durable choice, and streams cover high-throughput, replayable reads. Classic queue mirroring was removed in RabbitMQ 4.0, so teams migrating older HA designs should plan that change explicitly. For simple point-to-point work, a queue broker is usually the simpler and cheaper operation than a partitioned log.
Pulsar separates the roles. Stateless brokers route messages, Apache BookKeeper bookies persist data as a distributed write-ahead log, and a metadata store holds cluster state, which can be Oxia (recommended for new clusters), ZooKeeper or RocksDB. The practical advantage is that storage capacity grows by adding bookies without adding brokers, which suits workloads with large retained data volumes or many topics. The cost is more components to deploy, monitor and upgrade. If your volumes are modest and one team runs the cluster, Kafka or RabbitMQ will usually mean fewer moving parts. Before committing, check the Pulsar release policy against your upgrade calendar, since LTS support windows are set in months, not years.
Each option in brief, with its license
Apache Kafka is an Apache Software Foundation project released under Apache-2.0, and the project itself offers no paid edition. Kafka Connect ships within the same project for moving data between Kafka and other systems through source and sink connectors. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as the supported releases.
- License: Apache-2.0, with commercial support coming from third parties. Confirm who will support your build and on what terms.
- KRaft only: Kafka 4.0 removed ZooKeeper mode. ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x, and KRaft clusters older than 3.3.x should move to 3.9.x first.
- Java requirements: Since 4.0, brokers, Kafka Connect and tools require Java 17, and clients and Kafka Streams applications need at least Java 11.
- Kafka Connect: Connectors run in standalone or distributed mode and are managed through a REST API. Each connector carries its own license, separate from Kafka's Apache-2.0 terms.
- Security: SSL/TLS and SASL are optional, so clusters can run unsecured or mix secured and unsecured listeners. Confirm every listener is secured before production.
Check your release train against your upgrade window, and confirm the license of every connector you plan to run.
RabbitMQ server and its tier 1 core plugins are licensed under MPL 2.0, with some OCF files under Apache 2.0. The project is stewarded by Broadcom, and its support windows depend on whether you hold a commercial support license. RabbitMQ 4.3.6 was released on September 16, 2026, with community support until January 31, 2027.
- License: MPL 2.0 for the server and tier 1 core plugins, with some Apache 2.0 files. Check the LICENSE file against the components you deploy.
- Community support: 4.3.6 receives community support until January 31, 2027. Community support for 4.2 ended on July 31, 2026.
- Commercial support: Support beyond community dates requires a valid commercial support license. Commercial support for 4.2 runs to June 30, 2030, and lifecycle details are on the Broadcom support portal.
- Cluster Operator: The RabbitMQ Cluster Kubernetes Operator is published under MPL-2.0 in its GitHub repository, so confirm its terms alongside the server.
- Protocols: AMQP 1.0 became a core protocol in RabbitMQ 4.0. MQTT, STOMP and related WebSocket access come through plugins, and RabbitMQ Streams handle high-throughput stream access.
Confirm which plugins you need are tier 1 core, and plan upgrades against the community end dates in the release information.
Apache Pulsar is an Apache Software Foundation project licensed under Apache-2.0. Its release policy sets a predictable cadence: an LTS release every 18 months, with 24 months of active support and 36 months of security support. Pulsar 5.0 LTS was released on October 5, 2026. Pulsar 4.0 LTS remains on active support until October 21, 2026.
- License: Apache-2.0, from an Apache Software Foundation project with no separate commercial edition named in the release policy.
- LTS dates: Pulsar 5.0 LTS has active support until October 5, 2028 and security support until October 5, 2029. Pulsar 4.0 LTS has security support until October 21, 2027.
- Feature releases: Feature releases come every 3 months, each with 6 months of support, so plan on the LTS line for longer-lived clusters.
- Architecture: Stateless brokers route messages, Apache BookKeeper bookies provide persistent storage as a distributed write-ahead log, and a metadata store holds cluster state. Storage capacity grows by adding bookies independently of brokers.
- Metadata store: Oxia is recommended for new clusters, with ZooKeeper and RocksDB also available. Confirm which store your chosen version supports.
Confirm that your operations team can run BookKeeper and the metadata store, and match the LTS dates to your upgrade plan in the Pulsar release policy.
Redpanda is a source-available, Kafka-compatible streaming platform. It is not OSI-approved open source, so its license terms differ from the Apache-2.0 terms that cover Kafka and Pulsar. No version, license name or support window was researched for this comparison, so this tab works as a checklist for the vendor conversation rather than a fact sheet.
- License: Source-available, not OSI open source. Obtain the full license text and its restrictions in writing before comparing it with the Apache-2.0 options.
- Kafka compatibility: Test the clients, Kafka Connect connectors and tools you use, because protocol compatibility does not guarantee identical behavior under your workloads.
- Editions: Ask which features sit in free versus paid editions, and confirm that the features you need are included in the edition you would license.
- Support windows: Ask for the release and support dates for the exact version you plan to run, and compare them with the Kafka release train.
- Self-hosting: Confirm the supported deployment models, including whether air-gapped installation and your Kubernetes platform are supported.
Confirm the license terms with the vendor and run a compatibility test against your own workloads before you commit to a platform.
Licensing, support windows and what they cost you
Kafka and Pulsar are both Apache-2.0 licensed, and neither project sells a paid edition, so the license cost is zero and the money goes to people and infrastructure. RabbitMQ is different. Its server and tier 1 core plugins are MPL 2.0, but support is on dated windows: RabbitMQ 4.3.6 was released on September 16, 2026 with community support until January 31, 2027, and 4.2 community support ended on July 31, 2026. Longer support beyond those dates requires a valid commercial support license. For example, commercial support for 4.2 runs to June 30, 2030. Confirm the current commercial lifecycle and pricing with Broadcom on its support portal before you plan an upgrade path.
Kafka's support is set by release rather than by a vendor contract. The downloads page lists 4.3.1 (June 25, 2026), 4.2.2 (September 29, 2026) and 4.1.2 (March 17, 2026) as supported, and the project makes bugfix releases only for those lines. Rolling upgrades are supported from the last three releases to the latest. If your cluster still depends on ZooKeeper, it must move to KRaft before upgrading to 4.x, which is a migration project with its own effort and testing cost, not a version bump.
Pulsar uses a published release policy. Pulsar 4.0 LTS (October 21, 2024) has active support until October 21, 2026 and security support until October 21, 2027. Pulsar 5.0 LTS was released on October 5, 2026, with active support until October 5, 2028 and security support until October 5, 2029. Because 4.0 active support ends within weeks of this page's date, any Pulsar deployment on 4.0 should be planned for upgrade now. Ask your team or integrator to budget the recurring cost of upgrades, testing and on-call coverage, since these are the largest ongoing expenses for self-hosted brokers, whatever the license.
How to choose and pilot a broker
This sequence turns a shortlist of Kafka, RabbitMQ, Pulsar and Redpanda into a decision backed by your own workloads, license review and a pilot on the infrastructure you will run. Each step ends with a written output that the next step depends on.
Inventory workloads and protocols
Platform owners and the teams that produce and consume messages list each workload: event streams, task queues, IoT telemetry, or request and reply traffic. For each, record the protocols clients already speak, such as AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, or the Kafka client API, and the approximate message sizes and retention needs. Done when every producer and consumer has a row in a shared table that names its protocol and its retention requirement. Protocol gaps found here often decide the shortlist before any testing starts.
Confirm license and support requirements
Legal, procurement and the platform lead check each candidate's license and support model against your policy. Kafka and Pulsar are Apache-2.0, RabbitMQ server and its core plugins are MPL 2.0, and Redpanda is source-available. Confirm which support windows your organization can accept, and for RabbitMQ, whether community support dates fit your plan or a commercial support license is needed. Ask each vendor or project for its written lifecycle statement. Done when the team has a signed-off list of acceptable candidates with their license and support terms recorded.
Verify version and upgrade path
The platform team confirms which release line each candidate would start on and how it would be kept current. For Kafka, check the supported releases on the downloads page (4.3.1, 4.2.2 and 4.1.2 at the time of research) and the rule that rolling upgrades are supported from each release in the past year up to the latest. If you still run ZooKeeper-based clusters, plan the move to KRaft before any 4.x upgrade, and note that clusters older than 3.3.x should first reach 3.9.x. Done when a written upgrade path exists for each candidate, including the Java 17 requirement for Kafka brokers and Kafka Connect.
Test replay, ordering and delivery needs
Engineers write a small test harness that reproduces your most sensitive flows: replaying a consumer from an earlier offset or timestamp, preserving order across partitions or queues, and handling redelivery after a consumer failure. Run it against each candidate's replicated data structure, such as Kafka partitions, RabbitMQ quorum queues or streams, or Pulsar topics backed by BookKeeper. Record what each candidate guarantees and what your application must do itself. Done when the team has a pass or fail result per flow for each candidate, with the configuration used to get it.
Check security and authorization model
The security engineer reviews how each candidate authenticates clients, encrypts traffic and authorizes access. For Kafka, confirm the SASL mechanisms your identity setup needs (GSSAPI, PLAIN, SCRAM or OAUTHBEARER) and decide how ACLs will be managed, noting that in KRaft clusters the StandardAuthorizer stores ACLs in the metadata log and that resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Compare the equivalent controls for RabbitMQ and Pulsar. Done when the security review produces a checklist of required controls, with each candidate marked as meeting, partly meeting or not meeting it.
Run a pilot on target infrastructure
The platform team deploys the shortlisted candidates on the same cloud accounts, data center or air-gapped network where production will run, using the networking, storage and identity services you will use. Load the pilot with representative traffic, add a broker or node failure, and record latency, throughput and recovery behavior. Use your own infrastructure as the test bed, since results on a vendor demo cluster rarely carry over. Done when each pilot has a dated report with measured results and the failure tests it passed or failed.
Measure day-two operating tasks
The operations team performs the tasks it will repeat for years on each pilot cluster: a rolling restart, a version upgrade, adding capacity, rotating credentials and restoring from backup. For Pulsar, check how storage grows by adding BookKeeper bookies separately from brokers, and for RabbitMQ, how quorum queues behave during node maintenance. Time each task and log every manual step. Done when the operations log shows which tasks ran without intervention and which needed runbooks or specialist knowledge, which becomes the basis for the operating estimate in your quote request.
Decide and document the choice
The architecture group reviews the license, security, pilot and operations results side by side and records a decision with its reasons, the workloads it covers and the conditions that would trigger a re-review, such as a support window ending or a change in license terms. Share the written decision with the vendors or partners who will quote the implementation. Done when a signed decision record exists, with the rejected options and the reasons for rejecting them, ready to attach to the scope of work.
What running each broker demands from your team
Each broker shifts a different kind of work onto your platform team, from upgrade paths and runtime requirements to clustering, access control and licensing review. The cards below name the skill each one needs and the recurring work to plan for before you commit.
Kafka KRaft and Java 17 upkeep
Kafka 4.0 supports only KRaft mode, so any ZooKeeper-based cluster must migrate to KRaft before upgrading to 4.x. Since 4.0, brokers and Kafka Connect require Java 17, which means your JVM patching cycle now covers the broker fleet as well as your clients. Plan for the project's three releases a year, and confirm which of the supported lines (4.1.2, 4.2.2, 4.3.1) your upgrade window can absorb. Rolling upgrades are supported from the last three releases, so falling further behind forces a multi-step path.
Quorum queues replace mirroring
Classic queue mirroring was removed starting with RabbitMQ 4.0, so high availability now depends on quorum queues built on the Raft consensus algorithm or on streams. Teams migrating older configurations must redesign queue types, client settings and failure tests rather than copy old policies. Quorum queues need an odd number of replicas to keep a majority, so capacity planning becomes a Raft quorum exercise. Confirm your client libraries handle the queue type change before cutover.
Pulsar BookKeeper and metadata store
A Pulsar cluster runs three distinct layers: stateless brokers, BookKeeper bookies for persistent storage, and a metadata store. Your team must operate the bookie tier and choose the metadata store, which can be Oxia (recommended for new clusters), ZooKeeper or RocksDB. Storage grows by adding bookies independently of brokers, which is useful for capacity but adds a second stateful system to back up and monitor. Ask whether your staff already runs ZooKeeper or BookKeeper skills, since those skills change the effort on this platform.
ACL and authentication setup
Kafka supports SSL and SASL, with GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, and security is optional, so clusters can run with mixed secured and unsecured listeners. In KRaft clusters, ACLs live in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Someone must own certificate rotation, principal mapping and ACL reviews for every new topic and client. Pulsar and RabbitMQ require equivalent authentication and authorization work, so confirm which model your identity team can support.
Redpanda licensing review
Redpanda is a source-available, Kafka-compatible option, so its terms differ from the Apache-2.0 license that covers Apache Kafka and Apache Pulsar. Before adopting it, have legal and procurement review the license text, any restrictions on production use or redistribution, and what counts as a paid tier. Your team also needs to confirm which Kafka client, Connect and tooling behaviors match your existing estate. Re-run this review at each major upgrade, since license terms can change independently of the software.
Commercial lifecycle tracking
RabbitMQ community support ends on fixed dates, and long-term support beyond them requires a valid commercial support license. Confirm the commercial lifecycle details directly with the vendor's support portal before committing to a version, because the community window is shorter than many production refresh cycles. Pulsar publishes LTS and feature release windows, so calendar those dates alongside your change freeze schedule. Assign one owner to track end-of-support dates for every broker in production.
What do buyers ask before running a broker themselves?
What drives the cost of running a message broker yourself?
All three core brokers on this page are open source, so the license fee is not the main cost. The cost comes from infrastructure, people and operations. Infrastructure covers compute, storage and network for the brokers, and for Pulsar it also covers the BookKeeper bookies and the metadata store, which scale independently of brokers. Staff time covers installation, upgrades, capacity planning, monitoring, on-call response and disaster recovery testing. Security configuration such as TLS, authentication and authorization adds build and review effort. Infrastructure and staff time recur every year, while initial setup is largely one-time. When you request a quote, ask it to separate hosting, labor and any retainer, and to state which upgrade and support windows it covers.
Can you run Apache Kafka without depending on a vendor?
Yes. Apache Kafka is licensed under Apache-2.0, and the Apache Software Foundation project has no paid edition of its own, so there is no license fee to a vendor. That does not make running it free of cost. Your team or an implementation partner must handle deployment, KRaft cluster operation, the Java 17 runtime required for brokers and Kafka Connect, security configuration, upgrades and monitoring. Some companies sell support, management tooling or hosted services around Kafka, which is a separate purchase. Before production, decide who answers for defects and security fixes, and confirm in writing what any outside party covers beyond the Apache release.
How long does a migration from RabbitMQ or Kafka take?
No single duration applies, because the time depends on what your applications rely on. The main drivers are the number of producers and consumers that must change, the protocols in use, and how much message ordering and replay your applications depend on. RabbitMQ migrations need a queue type review, since classic queue mirroring was removed in RabbitMQ 4.0 and quorum queues or streams take its place. Kafka clusters that still use ZooKeeper must migrate to KRaft before upgrading to 4.x, and clusters older than 3.3.x should move to 3.9.x first. Testing, cutover planning and a rehearsed rollback add further time. Most DeployOpen engagements are fixed-scope, so ask for a timeline tied to a written dependency inventory.
Which broker tasks should our team own, and which can we outsource?
Your team should keep ownership of decisions that depend on your business and data: topic and schema design, retention periods, consumer contracts and who responds to alerts. Operational work can be split. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, and it offers ongoing support, upgrades and continuous testing as retainers. A practical split is to agree in writing which party runs upgrades, patch windows, backup restore tests and incident response, and which party owns application-level changes. Without that written split, upgrade work tends to fall between teams.
Is Redpanda fully open source or only source-available?
Redpanda is a source-available, Kafka-compatible option, and its license terms differ from the Apache-2.0 license that covers Apache Kafka and Apache Pulsar. Source-available means the code can be read under terms that may limit some uses, so read the license text and any usage restrictions before you commit. Kafka client compatibility does not carry licensing terms with it, and it does not guarantee identical behavior for every feature, admin tool or ecosystem integration. Confirm license terms, supported features and support scope directly with Redpanda, and test your own clients against it before comparing operating costs with Apache Kafka.
Which support end dates matter most when buying a broker?
Check the community and support end dates for the exact version you plan to run, because they set your upgrade schedule. For RabbitMQ, 4.3.6 has community support until January 31, 2027, and 4.2 community support ended on July 31, 2026, with commercial support for 4.2 running to June 30, 2030 for users with a valid commercial license. For Apache Kafka, the supported releases are 4.3.1, 4.2.2 and 4.1.2, and rolling upgrades are supported from the last three releases to the latest version. For Pulsar, 4.0 LTS active support ends on October 21, 2026, while 5.0 LTS is actively supported until October 5, 2028 and receives security support until October 5, 2029. Match these dates against your change calendar before you sign.
Does Kafka need extra security setup before production use?
Yes. Kafka security is optional, so clusters can run unsecured or mix secured and unsecured listeners unless you configure otherwise. Traffic between clients, brokers and tools can be encrypted with SSL/TLS, and authentication can use SSL or SASL with mechanisms that include GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so review that setting and the super user list during hardening. Test every client path against the chosen mechanism before cutover.
How DeployOpen scopes broker selection and implementation
DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the broker you choose runs on infrastructure you control. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For a broker decision, that means the written scope should name the candidates under evaluation, the workloads they must carry (for example, Kafka topics with compacted keys or RabbitMQ work queues with dead-letter routing), the environments in scope and the acceptance criteria for each. A selection pilot can run against the same written scope for each candidate, so the comparison rests on your workload rather than on a preferred product. DeployOpen does not publish a price list, and a quote follows from that written scope.
Ask for the pilot scope in writing before any build starts. It should cover the protocols your producers and consumers actually use, the replication settings you need, the authentication path (for Kafka, the SASL mechanisms your identity team supports), and the upgrade path for the release line you plan to run. Confirm each support window directly with the vendor or project, since release dates and lifecycle terms change; the Kafka downloads page, the RabbitMQ release information page and the Pulsar release policy are the natural starting points. Cost drivers differ by broker: staff time for cluster operations, the storage and compute footprint, and any commercial support licenses are the components to name in the quote, and each is one-time or recurring in a different way.
Compliance support is preparation only. DeployOpen can help configure the broker, document its controls and collect evidence for an assessment, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that determination, so the scope should say which framework controls the team needs evidence for and who will assess them. Security testing of the chosen platform can be scoped separately, and ongoing support, upgrades and continuous testing are available as retainers. Treat the written scope as the decision record: if a requirement is not in it, it is not part of the quote.
