Queues are durable or transient (non-durable). Metadata of a durable queue is stored on disk, so durable queues are recovered on node boot together with the messages in them that were published as persistent: to survive a broker restart an application must declare durable queues and publishers must mark published messages as persisted. Quorum queues must be durable because of the assumptions and requirements of their underlying replication protocol, and for quorum queues a delivery limit should be set to bound redeliveries. Transient (non-durable) non-exclusive classic queues are deprecated; the alternatives are durable queues, non-durable exclusive queues, or durable queues with a queue TTL for cleanup of unused queues. An exclusive queue can only be used by its declaring connection and is deleted when that connection closes, so exclusive queues should almost always be server-named. Durability does not affect a queue's throughput or latency, and in most cases durable queues are the recommended option. Scope: RabbitMQ. Reviewed October 4, 2026.
Durable queues for broker restart survival
Document v1 · published by Koskamo editorial · updated 2026-10-04
Source and provenance
- Original source
- www.rabbitmq.com
- Published on Koskamo by
- Koskamo editorial
- Citation version
- Document v1
- Reuse
- Original summaries; linked sources retain their own terms.