Community RabbitMQ, Tanzu RabbitMQ or third-party support?

rabbitmq.com publishes two dates for every release series. Community support means free security updates and bug fixes from the project. Long term support is extended commercial support, available to people who hold a valid commercial support licence. The commercial dates are labelled indicative, and the official lifecycle sits on the Broadcom support portal. Source: the rabbitmq.com release information page, checked 26 October 2026. Earlier series and patch-level dates are on RabbitMQ end of life dates.

Since 4.0 a new minor series has arrived roughly every six months: 4.0 in September 2024, 4.1 in April 2025, 4.2 in October 2025, 4.3 in April 2026 and 4.4 on 20 October 2026. The community window for each lasts seven to nine months, so staying inside it means one cluster upgrade, one client compatibility check and one change window about twice a year, sometimes with an Erlang/OTP change on top. The yearly cost is engineer hours per upgrade, the test environments to rehearse it in, and the risk of each rolling restart on a production message broker, multiplied by two.

If that cadence fits your release process, community RabbitMQ is the cheapest route and there is nothing to buy. If it does not, because a regulated change window comes once a year or applications are built around the broker's current behaviour, the choices are a Tanzu licence, whose commercial windows run longer, or an independent contract on the version you already run. Neither removes the upgrade; both let you schedule it.

Many teams run community RabbitMQ and call a consultant when something breaks. It works while you keep upgrading, and a good consultant can fix a cluster. It does not give you four things:

1. A response clock. rabbitmq.com describes community support as best effort, through GitHub, Discord, the mailing list and IRC. A consultant on an hourly rate has no obligation to answer at 3am.
2. Fixes for a series past its window. When a series leaves community support, the project stops publishing security fixes for it, and a consultant cannot ship a vendor patch. Only the commercial window or a provider that backports fixes does.
3. Context. An incident goes faster when the engineer already knows your queues, quorum queue sizing and monitoring. A new consultant starts from nothing each time.
4. Evidence. An auditor asking for supported software wants a contract that names the version, not an invoice.

RabbitMQ is an open-source message broker that speaks AMQP and routes messages into queues. In production it runs as a cluster, usually three nodes with quorum queues for high availability, so the loss of one node should fail over without losing confirmed messages. The incidents that need support are the ones failover does not cover: a disk or memory alarm that blocks publishers, a cluster that lost its majority, a backlog because consumers stopped, or an upgrade of RabbitMQ, Erlang or a client library that breaks a mission-critical application.

Under community support these are diagnosed from the logs and the documentation, with help from other users. Under Tanzu RabbitMQ the core engineers take the highest severity within 30 minutes. Under a third-party contract a named engineer who already knows your cluster does. Teams that run Apache Kafka or ActiveMQ alongside RabbitMQ face the same choice for each broker; message broker support options compared covers who supports what.

The edition changes who answers and for how long, not what the message broker does. Every edition of RabbitMQ is an asynchronous message queue broker: producers and consumers exchange messages through the broker, so each message is routed to the right queue and consumers receive messages from it. RabbitMQ supports AMQP 0-9-1, and AMQP 1.0 has been a core protocol since 4.0. MQTT (3.1, 3.1.1 and 5.0), STOMP and the streams protocol arrive as plugins. Java, .NET, Python (pika), Go, Ruby (Bunny) and PHP all have officially maintained client libraries (protocols and client libraries on rabbitmq.com, checked 26 October 2026).

The queue type you run matters more to support than the edition. A quorum queue is a durable, replicated queue built on the Raft consensus algorithm, has all data persisted to disk and is the documented choice for high availability when message loss would matter. Mirroring of classic queues was removed in 4.0, so a cluster that relied on it needs quorum queues or streams before it moves to a 4.x series. A stream keeps messages in an append-only log that consumers read without deleting them, which suits use cases such as replay, large backlogs and high-throughput fan-out. Streams do not support message priorities or dead-letter exchanges, and quorum queues are not the right fit for workloads that need the lowest latency (quorum queues and streams on rabbitmq.com).

On Kubernetes, the open-source RabbitMQ Cluster Operator provisions and manages clusters, and the Messaging Topology Operator manages virtual hosts, users and queues. Both are released under the Mozilla Public License 2.0 (operator overview). What a commercial licence adds, per rabbitmq.com, is 24/7 support plus features such as multi-data-centre disaster recovery, FIPS 140-2 compliance, intra-cluster compression, AMQP 1.0 over WebSocket and audit logging. A support provider covers the broker you run, with the protocols and queue types above, whichever edition that is.

Tanzu RabbitMQ is licensed per core, with Broadcom's 72-core minimum for direct orders. The rabbitmq.com support page lists AceMQ as an authorized licensing partner, so the licence can be bought through a partner that also provides the support contract and the engineers who answer the phone. AceMQ can license below the 72-core minimum. A licence does not include operations: Tanzu RabbitMQ is software and support, and somebody on your side or a partner's still runs the cluster. Counting rules and the minimum are covered in the licensing guide.

Match the situation, then check the dates above.

AceMQ has been in business for 10+ years and handles 40+ Sev 1 incidents a year. Its RabbitMQ upgrade engagements follow fixed rules: a lower environment first, rolling upgrades only, and no platform migration in the same production window as a version upgrade. Node failure, consumer reconnection and quorum elections are tested before go-live.

We compared community RabbitMQ, Tanzu RabbitMQ from Broadcom and third-party support from AceMQ on eight criteria: licence cost, response commitment, how long a release series is fixed, versions covered, upgrade pressure, features, who answers, and who each route is not a fit for. Every release date and support window comes from the release information on rabbitmq.com, checked on 26 October 2026. The Tanzu end-of-support dates are marked indicative there, so confirm your version with Broadcom or your provider before you rely on one. AceMQ sells one of the three routes, so the table says where its own route is not the right fit.