Last checked and updated on 01 May 2026What Is New in RabbitMQ 3.3
RabbitMQ 3.3 is a significant release focused on protocol support, management, and core stability. It introduced the MQTT plugin as a core component and made several under-the-hood improvements for production environments.
| Category | Key Changes |
|---|---|
| New Features | Official MQTT plugin, Shovel plugin improvements, AMQP 1.0 plugin (tech preview). |
| Improvements | Memory use optimization, better Windows service control, enhanced queue state reporting in management UI. |
| Bug Fixes | Fixes for clustering, message persistence, and AMQP connection handling. |
| Deprecated | Some older, less efficient internal data structures. |
How did RabbitMQ 3.3 improve protocol support?
The headline feature is the inclusion of the MQTT plugin as a core component. Before 3.3, MQTT support was community-driven; this release brought it into the main distribution, signaling first-class support for IoT and lightweight messaging use cases.
In practice, this meant you could enable MQTT with a single command: rabbitmq-plugins enable rabbitmq_mqtt. The plugin shared the same authentication and vhost system as AMQP 0-9-1, simplifying deployment. This matters because it opened RabbitMQ to a whole new ecosystem of devices and clients.
Additionally, the AMQP 1.0 plugin was updated as a tech preview. While not production-ready at the time, it laid groundwork for future interoperability with other messaging systems that use AMQP 1.0, like Azure Service Bus.
What management and monitoring enhancements were made?
RabbitMQ 3.3 refined the management UI and API, giving operators clearer insight into queue internals. The state of queues (e.g., idle, running) was reported more accurately, which was crucial for debugging bottlenecks.
The Shovel plugin, used for reliable message replication between brokers or clusters, received updates for better fault tolerance and configuration management. You could define shovels via the new runtime parameters feature, moving away from static config files.
For Windows deployments, service management was improved. Starting, stopping, and managing the broker as a Windows service became more reliable, which addressed a common pain point for teams deploying on Windows servers.
What core stability and performance changes should I know?
Memory usage was a key focus. The broker's internal memory accounting was tuned to be more aggressive in returning memory to the OS after large message spikes. This helped prevent the system from holding onto RAM unnecessarily.
Several bugs around mirroring and failover in clustered setups were fixed. One notable fix addressed an issue where a mirrored queue could get stuck in a synchronization loop under specific network partition scenarios.
Under heavy load with persistent messages, disk I/O handling was improved to reduce the chance of writes blocking the entire broker. This was a backend change that made the persistence layer more robust for high-throughput workloads.
FAQ
Is the MQTT plugin in RabbitMQ 3.3 production-ready?
Yes, its promotion to a core plugin signified it was stable and supported for production use. It implements MQTT 3.1 and supports QoS 0, 1, and 2, allowing seamless integration with IoT devices while leveraging RabbitMQ's existing clustering and management.
How do I configure a Shovel in 3.3 without editing the config file?
You can use runtime parameters via the management HTTP API or the CLI. For example, you can define a shovel by setting a parameter on a source server. This method is more dynamic and aligns with the move towards programmable infrastructure.
Were there any breaking changes in the management API?
Minor, non-breaking additions were made to the API for new metrics. Existing API endpoints remained stable, so upgrades from 3.2.x shouldn't break existing monitoring scripts or tools that consume the HTTP API.
Did the memory improvements help with large message sizes?
They helped more with scenarios involving many medium-sized messages. The improvements targeted how the Erlang VM managed memory chunks, reducing fragmentation. For single giant messages, you still needed to be mindful of your frame_max and memory high-watermark settings.
Should I use the AMQP 1.0 plugin in 3.3 for new projects?
No, it was explicitly marked as a "tech preview." It was useful for experimentation and interoperability testing, but for production workloads requiring AMQP 1.0, it was advised to wait for a later release where the plugin reached stable status.