Choosing RabbitMQ Queue Types: Quorum vs Classic Queues

The decision: replicated safety vs raw throughput

When you stand up a RabbitMQ cluster, the first queue-type decision is whether messages must survive a node loss. RabbitMQ offers quorum queues (Raft-based replication), classic queues, and the deprecated classic mirrored queues. The rule of thumb: default to quorum queues for anything you cannot afford to lose; use classic queues only when throughput matters more than durability.

Supported options at a glance

Trade-offs you should weigh

Quorum queues require an odd number of nodes (3 or 5) for effective majority consensus — a 2-node cluster cannot tolerate a node loss safely. They keep messages in memory as well as on disk, so memory can grow with backlogs; set max-in-memory-length if you expect accumulation. Feature support (TTL, priority, single active consumer) varies by version, so check your exact release's documentation.

Classic queues are the right call for high-rate, low-value, or replayable data where upstream systems can tolerate loss.

Declaring a quorum queue

Set the queue argument x-queue-type=quorum with durable=true; the queue must not be exclusive or auto-delete. Example with the Java client:

Map args = new HashMap<>();
args.put("x-queue-type", "quorum");
args.put("x-delivery-limit", 5);
channel.queueDeclare("orders", true, false, false, args);

Alternatively, apply a policy with queue-type=quorum so all matching queues are declared as quorum queues.

Validating the setup

On a 3-node cluster, publish persistent messages, then check member status with rabbitmq-queues quorum_status orders (or the management UI) to confirm all members are online and a leader is elected. Stop the node holding the leader and verify consumers still receive all acknowledged messages. For throughput, benchmark with PerfTest using --quorum-queue under your expected message size and rate. Never invent output — run the check yourself on your version.

Practical checks

• Confirm classic mirrored queues are deprecated in your release's deprecated-features list.
• Verify quorum queue feature support (TTL, priority) against your RabbitMQ version's documentation.
• Plan migration from classic mirrored queues as a declare-new-queues-and-move-consumers operation, not an in-place upgrade.

Limitations

Quorum queues are generally slower than non-replicated classic queues under high fan-out. If you need maximum throughput and can handle message loss upstream, classic queues without mirroring are the better fit — but you accept the risk of losing messages on node failure.