RabbitMQ 4.3: What's New, Release History & EOL Status

What Is New in RabbitMQ 4.3

RabbitMQ 4.3 is a feature release that solidifies the Khepri metadata store, introduces powerful new quorum queue capabilities, and removes several legacy components. The upgrade path is straightforward for clusters already on 4.2.x.

How does Khepri change cluster operations in RabbitMQ 4.3?

In RabbitMQ 4.3, Khepri is now the only metadata store, completely replacing Mnesia. This simplifies failure recovery and brings consistency to the cluster's control plane.

Cluster availability now depends on a majority of nodes being online, following Raft consensus semantics — the same model used by quorum queues and streams. This makes the system's behavior more uniform and predictable. The old partition handling strategies like pause_minority and autoheal are removed because they are no longer needed with a Raft-based store.

If you are upgrading from 4.2.x and already have the khepri_db feature flag enabled, the transition is seamless. If not, the node will automatically migrate metadata from Mnesia to Khepri on its first boot in 4.3. This is a one-time, automatic operation.

What new capabilities do Quorum Queues get in RabbitMQ 4.3?

Quorum queues receive a major upgrade in RabbitMQ 4.3 with four significant additions: strict priorities, delayed retry with backoff, consumer timeouts, and a 50% memory reduction for small messages.

Strict Priority Queues

Quorum queues now support 32 strict priority levels. Higher priority messages are always delivered before any lower priority ones, which is crucial for workload management. The Management UI displays per-priority message counts for each queue.

Delayed Retry with Backoff

Instead of building complex dead-letter or scheduler workarounds, you can now configure a quorum queue to delay redelivery of returned messages. The delay grows with each delivery attempt using the formula: min(min_delay × delivery_count, max_delay). For example, with a min_delay of 5 seconds and a max_delay of 60 seconds, the first retry waits 5s, the second 10s, the third 15s, and so on — capping at 60s. This is ideal for handling transient failures such as API rate limits or temporarily unavailable downstream services.

Consumer Timeouts

Consumer timeout enforcement has been moved directly into the quorum queue itself. When a consumer holds an unacknowledged message beyond the configured timeout, the message is returned to the queue. AMQP 1.0 clients receive a graceful released disposition, while AMQP 0-9-1 clients with consumer_cancel_notify enabled receive a basic.cancel instead of a full channel closure.

Memory Optimizations

A new compact message reference representation halves the per-message memory overhead for messages up to 32 KiB. For queues holding many small messages, this can significantly reduce RAM pressure without any configuration change.

Why were transient non-exclusive queues disabled in RabbitMQ 4.3?

Transient non-exclusive queues are a legacy pattern with poor durability semantics. They are now deprecated and disabled by default in RabbitMQ 4.3 to encourage the use of more reliable alternatives.

If you need a short-lived queue, use a durable queue with a x-expires (queue TTL) policy. If you need a temporary queue bound to a single client, use an exclusive queue instead. These alternatives provide clear, predictable lifecycle management and survive node restarts correctly.

If you must retain the old behavior during a transition period, you can opt in explicitly by setting deprecated_features.permit.transient_nonexcl_queues = true in rabbitmq.conf. However, this is not recommended for production environments.

How is AMQP 1.0 support improved in RabbitMQ 4.3?

RabbitMQ 4.3 introduces two key AMQP 1.0 enhancements that improve debuggability and integration with newer queue features.

First, when a message is rejected by a queue (for example, due to a max-length limit being reached), the Rejected outcome now includes the queue name and the rejection reason in its info field. This is particularly useful for fanout routing patterns where a single publish may target multiple queues — publishers can now identify exactly which downstream queue rejected the message and why.

Second, quorum queues with Single Active Consumer (SAC) now notify AMQP 1.0 consumers about active/inactive state changes via flow frame properties. This is a new capability in 4.3 that allows consumers to react immediately when they become the active consumer, improving overall responsiveness and reducing unnecessary polling.

What should I do before upgrading to RabbitMQ 4.3?

Upgrading to RabbitMQ 4.3 is only supported from 4.2.x. Follow this checklist before proceeding:

• Ensure you are on the latest 4.2.x patch release before starting. Direct upgrades from 3.x or earlier 4.x versions are not supported.
• Enable all required feature flags on your 4.2.x cluster: rabbitmq_4.0.0, rabbitmq_4.1.0, rabbitmq_4.2.0, and khepri_db.
• If you use AMQP 1.0, perform a rolling update after enabling rabbitmq_4.0.0 before moving to 4.3 to ensure protocol compatibility.
• Remove cluster_partition_handling from rabbitmq.conf. This setting no longer has any effect in 4.3 and can be safely deleted.
• Review deprecated features you rely on, such as transient non-exclusive queues, and decide whether to explicitly permit or migrate them.
• Plan for a rolling upgrade. RabbitMQ 4.3 nodes can run alongside 4.2.x nodes temporarily, but avoid running a mixed-version cluster for extended periods.