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 behavior: 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 behavior 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 behavior. 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.

Classic queue mirroring was deprecated in 2021 and removed in RabbitMQ 4.0. If a 3.13 cluster still relies on ha-mode policies, the replication those policies provide does not exist on 4.x, so the move to quorum queues has to be planned on 3.13, before or as part of the upgrade, not after it.

Start by finding every policy that turns mirroring on. RabbitMQ 3.13 ships two diagnostics for exactly this:

# exits non-zero if any policy enables classic queue mirroring
rabbitmq-diagnostics check_if_cluster_has_classic_queue_mirroring_policy

# lists those policies
rabbitmq-diagnostics list_policies_with_classic_queue_mirroring -s --formatter=pretty_table

The RabbitMQ documentation describes two migration routes:

1. Migrate by virtual host. Create a new virtual host on the same cluster, declare quorum queues there, and point applications at it by changing connection parameters. This is the most efficient route when application code no longer depends on features quorum queues lack, because the same code works against both queue types.
2. Blue-green to a new 4.x cluster. Build a 4.x cluster with quorum queues, move consumers and publishers across, and drain the 3.13 cluster. The RabbitMQ team publishes rabbitmqadmin v2 tooling for moving 3.13 definitions with mirrored classic queues to a 4.x cluster with quorum queues. This combines the version upgrade and the queue-type change into one cutover.

Either way, clear the incompatible features first. Exclusive or non-durable declarations, server-named queues and global prefetch need code changes. Queue arguments that only made sense for mirroring can usually be removed or moved into a policy. We prefer the blue-green route for estates that are also several minor versions behind, because it gives a rollback path that an in-place upgrade does not.

A quorum queue is declared by the client with the x-queue-type argument set to quorum. It cannot be set by policy, because a policy can change after declaration and a queue type cannot. By default the queue gets up to three members, one per node; x-quorum-initial-group-size changes that number.

Python with pika:

channel.queue_declare(
    queue="orders",
    durable=True,
    arguments={"x-queue-type": "quorum"},
)

Java client:

Map<String, Object> args = Map.of("x-queue-type", "quorum");
channel.queueDeclare("orders", true, false, false, args);

The queue must be durable and must not be exclusive, or the declaration fails. If an existing classic queue already has the same name, the declaration fails with a PRECONDITION_FAILED error, because the arguments do not match. That is the usual sign that a migration step was skipped.

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.

Membership is not automatic unless you turn it on. The rabbitmq-queues CLI manages it:

# add or remove one member of one queue
rabbitmq-queues add_member [-p <vhost>] <queue-name> <node>
rabbitmq-queues delete_member [-p <vhost>] <queue-name> <node>

# add a member on <node> for all matching queues, or only those with an even member count
rabbitmq-queues grow <node> <all | even> [--vhost-pattern <pattern>] [--queue-pattern <pattern>]

# remove all members hosted on <node>
rabbitmq-queues shrink <node> [--errors-only]

# spread leaders evenly across nodes
rabbitmq-queues rebalance quorum --vhost-pattern "production.*"

The usual sequence after adding a node is grow onto the new node, then rebalance so leaders do not all stay on the original three. Before decommissioning a node, run shrink against it so no queue loses a member it was counting on for its majority.

Continuous membership reconciliation automates the grow step. With quorum_queue.continuous_membership_reconciliation.enabled = true and a target_group_size, RabbitMQ grows queues that are below the target onto nodes that do not already host them. It runs every 60 minutes by default and also after events such as a node joining. It is off by default. auto_remove, which drops members on nodes that have left the cluster, is a separate setting and also off by default.