The short answer: use quorum queues by default, and keep classic queues for genuinely transient, high-churn work where losing a message on node failure is acceptable. That has been the right guidance for a while now, but the reasoning matters more than the rule — because the two exceptions and the migration cost are what actually bite teams.
This question comes up constantly in RabbitMQ assessments, usually in one of two forms: an operator who inherited a cluster full of classic queues and wants to know whether converting is worth the disruption, or a team designing something new that needs a defensible default.
The Three Queue Types, Compared on What Matters
RabbitMQ has three storage mechanisms worth knowing, and the third one is not a queue at all — which is exactly why it gets misused.
The row that decides most designs is Survives power loss. A quorum queue replicates and flushes each message to disk on a quorum of nodes before it confirms to the publisher. A classic queue persists locally but has no replication, so a node failure takes the queue with it. A stream replicates but does not fsync before confirming, which means it carries the same exposure Kafka does — fine for telemetry, wrong for payments.
The row people misread is Reads. Classic and quorum queues are destructive: a consumer takes the message and it is gone. Streams are non-destructive: the message stays, and many consumers can read the same history independently at their own offset. If you find yourself wanting to re-read messages from a queue, you want a stream.
Why a Quorum Queue Can Afford to fsync
The usual objection to quorum queues is that flushing to disk on every message must be slow. It is not, and the reason is a design decision worth understanding because it is also the sharpest technical difference between RabbitMQ and Kafka.
Quorum queues share a write-ahead log. One flush to disk covers messages destined for many different queues, so the cost is amortised across the whole broker instead of being paid separately by each queue. That is what makes it practical to have many queues, replication with fsync, and real throughput at the same time — three properties you normally have to choose two of.
Kafka works the other way: fsync happens per partition, which makes it expensive enough that Kafka discourages it by default and relies on replication alone. That is not a flaw so much as a different bet, but it means an acknowledged Kafka message is in the page cache of several brokers rather than on disk.
There is a second, subtler benefit. Raft in a quorum queue covers delivery state, not just message content — which message is checked out to which consumer, and how many credits that consumer holds. After a leader failover the new leader resumes with that state intact, rather than redelivering a whole batch. That mechanism is what makes per-message TTL, priorities, delays, and dead-letter routing possible at all.
What You Give Up by Converting
Most guidance stops at "use quorum queues." The useful part is the two things that actually catch people out.
Memory per queue is higher. A quorum queue carries Raft state and holds more memory than a classic queue does. If your design has thousands of small, short-lived queues — a common per-session or per-request pattern — converting all of them at once can push a cluster into memory pressure that did not exist before. This is the single most common way a well-intentioned migration causes an incident.
Priority does not work the same way. Classic queues implement priority through x-max-priority. Quorum queues handle priority differently and do not provide the identical mechanism, so a queue whose behaviour depends on classic priority semantics needs its design revisited rather than simply re-declared. Find these before you plan the migration, not during it.
There is also a hard ceiling worth knowing: a quorum queue is not sharded. It tops out around 80,000 messages per second with replication and fsync, and you cannot split one queue across nodes to go faster. Aggregate throughput across many queues scales fine, but a single very hot flow needs application-level sharding — publishing across N queues with a routing key that distributes load. We cover that constraint and how it compares to Kafka partitioning in RabbitMQ vs Kafka.
Choosing, and What a Conversion Actually Costs
Four questions settle it for a given queue.
The warning on that chart is the operational reality: queue type is fixed at declaration. There is no in-place conversion. Migrating means declaring a new quorum queue, pointing publishers and consumers at it, draining the classic queue, and removing it once empty. On a live system that is a coordinated change with a drain window, not a config edit.
The sequencing that works: convert the queues carrying work you cannot afford to lose first, in small batches, watching memory as you go. Leave genuinely transient queues classic. Resist the urge to convert everything in one pass — that is precisely the change that turns a safety improvement into an outage.
If you are weighing a conversion across a large estate and want the memory and priority gotchas found before you start rather than during, that is a normal part of a RabbitMQ health check — or talk to AceMQ about scoping it.
FAQ
What is the difference between a classic queue and a quorum queue?
A classic queue lives on one node with per-message persistence; if that node fails, the queue and its contents are unavailable until it returns. A quorum queue is replicated across an odd number of nodes using Raft consensus and flushes each message to disk on a quorum of replicas before confirming to the publisher. Classic is local and fast to churn; quorum is replicated and safe, and is the recommended default for anything you cannot afford to lose.
Are quorum queues slower than classic queues?
Somewhat, and by less than most people expect. A single quorum queue lands around 80,000 messages per second with replication and fsync; a classic queue runs somewhat higher because it does neither. Quorum queues stay fast because they share a write-ahead log, so one fsync covers many queues and the cost is amortised rather than paid per queue.
When should I still use a classic queue?
When the work is genuinely transient and high-churn and losing a message on node failure is acceptable — cache invalidation broadcasts, ephemeral notifications, scratch work that will be regenerated anyway. Classic queues also hold less memory per queue, which matters if you run very large numbers of small, short-lived queues.
Can I convert a classic queue to a quorum queue in place?
No. Queue type is fixed at declaration, so conversion means declaring a new quorum queue, moving publishers and consumers to it, draining the classic queue, then removing it. Plan it as a migration with a drain window. Converting thousands of queues in a single pass is the migration that most often goes wrong.
Do quorum queues support message priority?
Not in the same way. Classic queues support priority via the x-max-priority argument; quorum queues handle priority differently and do not offer the identical mechanism, so a queue depending on classic priority semantics needs its design revisited rather than simply converted. That and higher memory use per queue are the two gotchas that catch teams mid-migration.
How many nodes do quorum queues need?
An odd number, with three as the practical baseline — that tolerates one node failure while keeping a majority. Five is common in larger deployments and tolerates two. Beyond five the consensus overhead grows without much added safety, so larger clusters are usually driven by something other than quorum requirements.
Are streams a replacement for quorum queues?
No — they solve a different problem. A stream is an append-only log with non-destructive reads, so consuming does not remove the message and many consumers can read the same history independently. A quorum queue is a work queue with destructive reads and per-message acknowledgement. Streams also do not fsync before confirming, so they carry a weaker durability guarantee.
