Classic Queues

The original, single-node queue

Classic queues are RabbitMQ's original queue type. Their data lives on one node. Modern versions use the version 2 storage format, which keeps memory use low by writing messages to disk efficiently rather than holding large backlogs in memory. Classic queues support every feature, including non-durable and exclusive queues, priorities (up to 255 levels, though a few is recommended), and very high throughput for transient data. The old classic mirrored queues (high-availability replication of classic queues) were deprecated for years and are removed in RabbitMQ 4.0; replicated data now belongs in quorum queues or streams. Use classic queues for temporary or non-critical data: RPC reply queues, exclusive per-connection queues, caches of work that can be regenerated, or very high-throughput transient messages where losing a node's contents is acceptable.

Three queue types

Classic queues live on one node; quorum queues and streams replicate across nodes.

When to choose which queue type

A quick decision table.

need                                                    queue type
------------------------------------------------------  ----------------
important work or events that must not be lost           quorum queue
replay, many consumers reading the same data, big logs   stream
temporary RPC reply / exclusive per-connection queue     classic (exclusive / auto-delete)
non-critical, very high-rate transient messages          classic
replicated classic (mirrored) queues                     removed in 4.0 -> use quorum

Plan migrations off mirrored queues

Systems upgraded from RabbitMQ 3.x may still declare mirrored classic queues through policies. Migrate them to quorum queues before upgrading to 4.x, using a new queue name or a blue-green cluster migration.

Quick check: What replaced classic mirrored queues for replicated, durable messaging in RabbitMQ 4.x?

• Quorum queues (and streams)
• Exclusive queues
• Auto-delete queues
• Headers exchanges