RabbitMQ 4.2 introduces SQL filter expressions for streams, enabling powerful broker-side message filtering.

In our benchmarks, combining SQL filters with Bloom filters achieved filtering rates of more than 4 million messages per second — in highly selective scenarios with high ingress rates. This means only the messages your consumers actually care about leave the broker, greatly reducing network traffic and client-side processing overhead.

Khepri, the new Raft-based RabbitMQ metadata store, became fully supported with RabbitMQ 4.0. Starting with the next release series, RabbitMQ 4.2, we consider Khepri to be mature enough to become the default metadata store, especially given its substantial data safety and recovery improvements over Mnesia.

We have performed a number of benchmarks, showing significant performance improvements in many metadata operations. A comparison table can be found below.

RabbitMQ 4 has been out for some time by now, and we have covered some of the goodies it comes with, compared to its predecesor, RabbitMQ 3.13. Some examples are improved performance, Native AMQP 1.0, new Quorum Queue features, bringing closer feature parity with Classic Queues.

Attention Debian and Ubuntu users: our apt repositories are moving..

The existing repos, ppa1.rabbitmq.com and ppa2.rabbitmq.com, will remain in operation until Nov 1, 2025 but not receive any new updates.

RabbitMQ Go Stream client 1.5.8 is a newbug fix release that includes a critical fix.

The fix reverts the pull request 393 that introduced a dangerous bug where the library skipped chunk delivery when the channel's maximum capacity was reached. In practical terms, message dispatch to the application would stop.

The bug was triggered when the consumer was experiencing a near peak delivery pressure for some time, or when the consumer was consistently slow to process the deliveries.

Affected versions​

The bug affects the following versions: 1.5.5, 1.5.6 and 1.5.7.

We strongly recommend updating the client to 1.5.8 as soon as possible.

RabbitMQ is not affected by CVE-2025-32433, a vulnerability in the Erlang's SSH library. RabbitMQ does not use SSH, neither the server nor the client parts.

We are delighted to announce support for AMQP 1.0 over WebSocket in VMware Tanzu RabbitMQ 4.1.

This feature enables any browser-based application to communicate with RabbitMQ using AMQP 1.0, paving the way for a wide range of efficient browser-based business messaging scenarios.

RabbitMQ 4.1.0 is a new minor release that includes multiple performance improvements, and a number of features such as thew new peer discovery mechanism for Kubernetes.

See Compatibility Notes below to learn about breaking or potentially breaking changes in this release.

RabbitMQ 4.0.9 is a new patch release in the 4.0.x series.

Release Artifacts​

Release artifacts can be obtained on GitHub as well as RPM, Debian package repositories.

Community Support Now Only Covers the 4.1.x Series​

With the release of RabbitMQ 4.1.0, this series is no longer covered by community support.

Future 4.0.x releases will only be available to paying customers via the Broadcom customer portal.

All non-paying users must upgrade to 4.1.0 in order to be covered by community support from the core team.

Upgrade Guidance​

If upgrading from a version prior to 4.0, please consult the 4.0 release notes.

RabbitMQ 4.1 is around the corner (update: has been released) and, as usual, apart from new features, we have made some internal changes that should provide better performance.

There are at least 4 notable changes:

1. Lower and more stable memory usage for quorum queues
2. Much better performance when consuming a long quorum queue
3. Better performance for Websocket connections
4. Lower memory usage and/or higher throughput for TCP connections