RabbitMQ Queue Type Decision Worksheet

Use this page to decide a queue type per workload and to find what a migration between types will break. It does not explain how quorum queues or streams work internally: the quorum queue article covers Raft, fsync and failover, the streams guide covers retention, offsets and super streams, and the durability article covers what persistence actually guarantees.

Work down the questions for each workload; the first yes decides the type, and later questions only refine the configuration. If every answer is no, the workload is low-stakes and a classic queue is fine.

Each worksheet answer comes from a row below, so check the rows your application depends on before you commit. Version notes reflect RabbitMQ 4.4; several rows changed in 4.3.

A queue's type cannot be changed in place, and the behaviours below do not carry over, so check the application against this list before you declare the new queue. Migrations that skip it tend to fail in the application rather than in the broker.

Classic to quorum

• Exclusive, server-named and transient declarations fail. Keep those queues classic; they are usually RPC replies and per-connection scratch queues.
• Global QoS consumers get a channel error. Switch to per-consumer prefetch, the default in several popular clients.
• x-overflow reject-publish-dlx is not supported. Use reject-publish, which is also what at-least-once dead-lettering requires.
• Redelivery is no longer unlimited. A message redelivered more than the delivery limit (20 by default) is dropped, or dead-lettered if a DLX is set. The docs recommend a dead-letter configuration on every quorum queue; a policy with delivery-limit changes the limit, and from 4.3 that applies without redeclaring the queue.
• Priority semantics change. x-max-priority is ignored, every quorum queue has 32 strict levels, and a message with no priority is treated as 4 rather than the classic default of 0.
• Queue TTL is only partial. The lease is not renewed when the queue is redeclared.
• Consumer exclusivity is not available. Use single active consumer instead.
• Memory scales with depth. At least 32 bytes per message (about 1 MB per 30,000 messages), plus 16 bytes when any message TTL is set.

Queue to stream

• Consuming no longer removes the message. The application must track its offset and handle replays.
• Acknowledgements and prefetch are mandatory. Acks act as the credit that advances the consumer.
• TTL and length limits become retention. Without max-age or max-length-bytes the log grows until the disk runs out.
• No dead-lettering, priorities, consumer priorities or poison message handling. Anything relying on them needs another design.
• Streams do not react to memory alarms. They use minimal RAM, so watch disk instead.

Any change of type

• The type is set only at declaration. x-queue-type cannot be set or changed by a policy.
• Redeclaring with a different type fails. The property equivalence check raises a channel error; quorum_queue.property_equivalence.relaxed_checks_on_redeclaration = true exists for applications that cannot be redeployed quickly.
• Messages do not move by themselves. Declare the new queue under a new name or on a new cluster, move messages with a shovel, then repoint bindings, policies and consumers.

Any queue that relied on mirroring has had no replica since 4.0, so the first step is to find those queues and decide which ones need replication back. This is the order we run it in.

1. Find mirroring in use. rabbitmq-diagnostics check_if_any_deprecated_features_are_used detects classic queue mirroring; then list queues and policies in every vhost, not just the default: rabbitmqctl list_queues name type policy --vhost <vhost> and rabbitmqctl list_policies --vhost <vhost>.
2. Separate the queues that cannot become quorum queues. Exclusive, server-named and transient queues stay classic.
3. Check the application against section 3. Global QoS, reject-publish-dlx, priorities and the delivery limit are the four we find most often.
4. On 3.13.x, migrate with rabbitmqadmin v2. It automates the move from mirrored classic queues to quorum queues as a blue-green deployment.
5. Clear the ha- keys from the policies. On 4.x they do nothing, and leaving them makes the next person think the queues are still replicated.
6. Re-baseline throughput before tuning. Quorum queues persist every message before confirming, so latency differs from an unreplicated classic queue. We recommend measuring first and not chasing the old numbers by cutting the replica count.

Quorum queues trade memory and disk I/O for safety, so size those two before the first workload lands.

• Members: three unless you need to survive two failures. A quorum queue is declared with up to three members by default; three tolerate one node failure and five tolerate two, and the docs note that more members generally means lower throughput.
• Memory per message: at least 32 bytes of index. That is about 1 MB per 30,000 messages per queue, whatever the message size, so set max-length on every queue to cap it.
• Memory for the WAL: three times its limit. The write-ahead log defaults to 512 MiB, and the docs recommend at least three times the effective WAL limit in node memory, four times for high-throughput systems.
• Disk: the fastest you have. Quorum queues persist all data before doing anything else.
• Prefetch: higher than you used with classic queues. The docs note quorum queue consumers benefit from higher prefetch so they are not starved while acks flow.
• Backlog: heading past millions means a stream. Do not answer it with a bigger quorum queue.