Last checked and updated on 06 Jun 2026
What Is New in RabbitMQ 3.8
RabbitMQ 3.8 introduces major improvements focused on data safety, operational resilience, and modern observability. The key changes are summarized below.
| Category | Key Changes |
|---|---|
| New Queue Type | Quorum Queues for strong consistency and safer replication. |
| Operational Features | Feature Flags for rolling upgrades; Single Active Consumer for consumer redundancy. |
| Observability | Built-in Prometheus endpoint and Grafana dashboards. |
| Security & Auth | New OAuth 2.0 / JWT authentication backend. |
| Core Server | Configurable max message size; new queue overflow behavior; reduced binding churn. |
| CLI & Management | New health check commands, quorum queue tools, and feature flag management UI. |
| Plugin Updates | MQTT, Shovel, Federation, and Web plugin improvements and bug fixes. |
How does RabbitMQ 3.8 improve queue replication and safety?
The headline feature is Quorum Queues. They replace mirrored queues as the recommended replicated queue type for most use cases.
Built on the Raft consensus algorithm, Quorum Queues prioritize data consistency. They offer non-blocking synchronization for new followers and eliminate the "throw away data on rejoin" behavior of classic mirrored queues. This makes node maintenance and recovery more predictable and safer.
Quorum Queues also introduce a delivery limit policy, letting you automatically drop messages after a certain number of redeliveries to handle poison messages. In practice, this means fewer manual interventions and more resilient systems.
What operational hurdles does 3.8 remove for cluster upgrades?
Feature Flags are the answer. They allow a RabbitMQ cluster to be upgraded from 3.7.x to 3.8.x one node at a time without downtime.
The new subsystem holds back new features until all nodes in the cluster are upgraded and an administrator explicitly enables them. This eliminates the old requirement for a full cluster shutdown during major version upgrades, significantly reducing operational complexity.
New CLI Tools for Health and Rebalancing
The rabbitmq-diagnostics tool now offers tiered health checks. The new rabbitmq-queues tool lets you rebalance queue leaders across the cluster after an upgrade, preventing hot spots.
How is monitoring and observability enhanced?
RabbitMQ 3.8 has native Prometheus support. Metrics are exposed on an HTTP endpoint, ready for scraping.
This is complemented by a set of official Grafana dashboards for visualization. The built-in management UI's metric collection can be disabled if you prefer using this modern observability stack. New metrics like "dropped unroutable messages" and "connection churn" provide deeper insight into broker behavior.
What are the new options for authentication and consumer management?
A new plugin enables OAuth 2.0 authentication using JWT tokens. Clients can use access tokens from an external provider, with permissions mapped to OAuth scopes. This facilitates integration with centralized identity providers.
Single Active Consumer
This feature provides a cleaner alternative to exclusive consumers. You can attach multiple consumers to a queue, but only one is active at a time. If it fails, another takes over automatically. This is transparent to the clients and simplifies building redundant consumer setups.
What core server and plugin improvements should I know about?
Several tweaks improve stability and debuggability. The maximum message size is now configurable (default is 128 MiB). A new queue overflow behavior, reject-publish-dlx, rejects publishes and dead-letters the message when a queue is full.
High queue churn (frequent creation/deletion) is less expensive due to changes in how default bindings are stored. For plugins like Shovel and Federation, sensitive credentials in runtime state are now encrypted to prevent accidental logging.
The MQTT plugin now uses a cluster-wide, consistent check for Client IDs, requiring a majority of nodes to be available for client connections.
FAQ
Can I upgrade from RabbitMQ 3.7 to 3.8 without downtime?
Yes, using rolling upgrades and the new Feature Flags system. You can upgrade nodes one by one while the cluster remains operational. Ensure you're on at least 3.7.18 before starting.
Should I use Quorum Queues or Classic Mirrored Queues now?
For new projects requiring data safety, use Quorum Queues. They offer stronger consistency guarantees and better behavior during node failure and recovery. Classic mirrored queues are not deprecated but Quorum Queues are the future.
Does the built-in Prometheus support replace the Management plugin?
No, it's an alternative. You can use the Prometheus endpoint for metrics and Grafana for dashboards, or continue using the Management UI. You can even disable the Management UI's metrics collection to reduce load if you use Prometheus.
My client library works with 3.7.x. Will it break with 3.8?
No. Client libraries compatible with RabbitMQ 3.7.x remain compatible with 3.8.0. The wire protocol is unchanged for core AMQP 0-9-1 operations.
What is the most critical Erlang/OTP compatibility note?
RabbitMQ 3.8 requires Erlang 21.3 or later. If you are upgrading Erlang and RabbitMQ simultaneously, you must upgrade RabbitMQ first, as CLI tools from pre-3.7.7 releases will fail on Erlang 21+.