RabbitMQ Classic vs Quorum Queues: Which to Use and How to Migrate

Use quorum queues for anything where losing a message matters. Use classic queues only for transient, non-replicated workloads — short-lived RPC replies, exclusive consumers, and server-named temporary queues. Quorum queues are the modern replacement for classic mirrored queues, which were removed entirely in RabbitMQ 4.0, so most teams still running mirrored setups are on a migration clock rather than making a free choice.

This guide covers what a quorum queue actually is, the concrete differences, what quorum queues do not support, and a migration path we have run on production clusters.

A quorum queue is a modern queue type built on the Raft consensus algorithm. Instead of one primary copy with optional mirrors, it maintains a set of replicated members — one leader and several followers — spread across the nodes of a cluster.

Writes are confirmed only once a majority of members have accepted them. That majority requirement is what gives quorum queues their data safety guarantee, and it is also what defines their failure behaviour: three members tolerate one node loss; lose two and the queue stops accepting writes by design rather than risking divergence.

Members are placed one per node. In a five-node cluster, a three-member queue occupies three nodes and leaves two unused — replication factor is independent of cluster size.

Use them when the message represents real work — an order, a payment, a job that must not vanish. This covers the large majority of enterprise messaging, which is why replication is now the sensible default queue type for new RabbitMQ services.

Use classic queues when the queue is genuinely disposable: RPC reply queues bound to one connection, exclusive queues that should die with their consumer, or server-named temporary queues. These are cases where replication adds cost and the unsupported features are exactly the ones you need.

Use streams when multiple independent consumers need to read the same messages, or you need replay over a retention window.

This is where migrations break, so check it before you plan one. Quorum queues do not support:

• Non-durable queues — they are always durable
• Exclusive queues — incompatible with the replication model
• Server-named queues — the name must be declared explicitly
• Global QoS prefetch — only per-consumer prefetch works. See tuning prefetch count for the implications
• Consumer exclusivity — use Single Active Consumer instead

Applications relying on any of these need a code change, not just a queue type change.

Starting with RabbitMQ 4.0, the delivery limit for quorum queues defaults to 20. After twenty delivery attempts a message is dropped or dead-lettered rather than redelivered indefinitely.

Before 4.0 there was no limit, which meant a consistently failing consumer could redeliver a poison message forever. The new default is a safety improvement, but it changes behaviour on upgrade: if your application depends on unlimited retries you will start losing messages you previously kept.

Set x-delivery-limit to raise it, or -1 to restore the old unlimited behaviour. Restoring it is not recommended — configure a dead-letter queue instead so failures are captured rather than looped.

A queue's type is fixed at declaration and cannot be changed by policy. Migration therefore means creating new queues, not altering existing ones.

1. Audit first. Find every queue using exclusivity, server-named declaration, or global prefetch. These need application changes before anything else happens.
2. Declare the new queue with the x-queue-type argument set to quorum. Three members is the practical default for high availability.
3. Drain the old queue. Point consumers at both, let the classic queue empty, then stop publishing to it.
4. Cut publishers over once the old queue reads zero.
5. Delete the classic queue only after a full retention period has passed with no issues.

The Shovel plugin can move messages between the two if draining in place is not an option. Run the whole sequence in staging first — the unsupported-feature list is where teams discover problems, and discovering them in production means an emergency rollback.

If you are also moving between major versions, sequence it carefully alongside upgrading RabbitMQ 3.x to 4.x without downtime.

Quorum queues are not universally slower, but the tradeoff is real. Every write waits for majority acknowledgement, which adds latency compared to a single unreplicated copy. In exchange, throughput under sustained load is far more predictable than classic mirrored queues ever managed — mirroring degraded badly with queue length, and quorum queues do not.

Keep queues short regardless. A quorum queue holding millions of messages will behave worse than one holding thousands, because every member stores the full backlog on disk.

Planning a migration and unsure which queues are safe to move? AceMQ runs these on production clusters, including the audit step most teams skip. Talk to an AceMQ engineer.

Three things regularly bite teams after migration.

Membership is managed explicitly. Adding a node to the cluster does not add it to existing queues. Use add_member, delete_member, grow, and shrink to manage membership deliberately. Teams that scale out and assume replication follows are surprised when a queue still has members on only the original three nodes.

Kubernetes maintenance needs a broker drain. During a 2026 cluster assessment we traced recurring quorum loss to node maintenance performed without draining the broker first. A Kubernetes drain evicts the pod, but the node needs its own graceful shutdown so members can hand off leadership. Skipping it turns routine patching into an outage.

Check your patch version before redesigning. On the same engagement we isolated node recognition errors to a defect in the 4.2.3 release, resolved in later 4.2.x builds and the 4.3 series. Membership errors that survive a clean restart and correct configuration are worth checking against release notes first. Our RabbitMQ troubleshooting guide covers the wider diagnostic path.

For disaster recovery, confirm the standby cluster activates only on primary failure. One that comes up alongside a healthy primary causes split-brain, and recovery then requires manual node recreation and re-election.