A previous post gave an introduction to stream filtering, a new and exciting feature in RabbitMQ 3.13. In this post we cover the internals of stream filtering. Knowing the design and implementation will help you to configure and use stream filtering in the most optimal way for your use cases.

Note: RabbitMQ 3.13 is in development at the time of writing

Stream filtering is a new feature in RabbitMQ 3.13. It allows to save bandwidth between the broker and consuming applications when those applications need only a subset of the messages of a stream.

Keep reading to find out how stream filtering works and see it in action.

Native MQTT released in RabbitMQ 3.12 has delivered substantial scalability and performance improvements for IoT use cases.

RabbitMQ 3.13 will support MQTT 5.0 and will therefore be the next big step in our journey to make RabbitMQ one of the leading MQTT brokers.

This blog post explains how the new MQTT 5.0 features are used in RabbitMQ.

RabbitMQ 3.12 will be released soon with many new features and improvements. This blog post focuses on the the performance-related differences. The most important change is that the lazy mode for classic queues is now the standard behavior (more on this below). The new implementation should be even more memory efficient while proving higher throughput and lower latency than both lazy or non-lazy implementations did in earlier versions.

For even better performance, we highly recommend switching to classic queues version 2 (CQv2).

RabbitMQ now has an official Discord server started by the core team. If you prefer Discord to Slack, feel free to join it and discuss all things RabbitMQ!

RabbitMQ’s core protocol has been AMQP 0.9.1. To support MQTT, STOMP, and AMQP 1.0, the broker transparently proxies via its core protocol. While this is a simple way to extend RabbitMQ with support for more messaging protocols, it degrades scalability and performance.

In the last 9 months, we re-wrote the MQTT plugin to not proxy via AMQP 0.9.1 anymore. Instead, the MQTT plugin parses MQTT messages and sends them directly to queues. This is what we call Native MQTT.

The results are spectacular:

1. Memory usage drops by up to 95% and hundreds of GBs with many connections.
2. For the first time ever, RabbitMQ is able to handle millions of connections.
3. End-to-end latency drops by 50% - 70%.
4. Throughput increases by 30% - 40%.

Native MQTT turns RabbitMQ into an MQTT broker opening the door for a broader set of IoT use cases.

Native MQTT ships in RabbitMQ 3.12.

Quorum Queues are a superior replacement for Classic Mirrored Queues that were introduced in RabbitMQ version 3.8. And there are two complementary reasons why you would need to migrate.

First of all, Classic Mirrored Queues were deprecated in 3.9, with a formal announcement posted on August 21, 2021. They will be removed entirely in 4.0

But also they are more reliable and predictable, faster for most workloads and require less maintenance - so you shouldn’t feel that your hand is being forced without no apparent reason.

Quorum Queues are better in all regards, but they are not 100%-compatible feature-wise with Mirrored Queues. Thus the migration can look like a daunting task.

After a sneak peek into the future performance improvements, this post outlines a few possible migration strategies and includes guidance on how to deal with incompatible features. The Migrate your RabbitMQ Mirrored Classic Queues to Quorum Queues documentation is also available to help you through the migration process.

Team RabbitMQ and community members have recently identified a curious scenario where a freshly started node could consume a surprisingly high amount of memory, say, 1.5 GiB or so. We’d like to share our findings with the community and explain what short term and longer term workarounds are available.

We intend to release RabbitMQ 3.11.0 on 5 September 2022. While we have been testing it internally for some time, with production-like workloads, we need your help to check that it is as stable and reliable as we believe it is.