RabbitMQ 4.0 Breaking Changes: The Checklist Before You Leave 3.13

The short answer

RabbitMQ 4.0 is a major version, and its release notes list a short set of breaking changes that decide whether a 3.13 cluster can move at all. Classic queue mirroring is gone. The default maximum message size drops from 128 MiB to 16 MiB. Quorum queues get a default delivery limit of 20. AMQP 1.0 becomes a core protocol that is always on. And the only supported upgrade path is from 3.13.x, with every stable feature flag enabled first.

None of these is hard on its own. Together they touch the broker configuration, queue topology and consumer behaviour, so each needs a check before the move, not after it.

The breaking changes in RabbitMQ 4.0

Classic queue mirroring is removed

After three years of deprecation, mirroring was removed completely. A classic queue on 4.x is a single-node queue. Any queue that relies on a mirroring policy for availability has to become a quorum queue or a stream before you leave 3.13. It is the largest job on this list, covered step by step in migrating classic mirrored queues to quorum queues.

A smaller change sits alongside it. CQv1, the original classic queue storage layer, was removed apart from the code needed to upgrade to CQv2. Non-replicated classic queues remain fully supported, and are still the right type for RPC reply queues.

The default maximum message size is 16 MiB

The default max_message_size fell from 128 MiB to 16 MiB. A producer that publishes a larger message gets it rejected by the broker on 4.x. You can raise the limit in rabbitmq.conf, but check the log of large-payload producers first. Large objects are usually better stored elsewhere, with the message carrying a reference.

Quorum queues have a delivery limit of 20

A message redelivered more than 20 times is dead-lettered if the queue has a dead-letter exchange, and dropped if it does not. This ends infinite fail-and-requeue loops, but a consumer that retries by requeueing forever will now receive a message 20 times and then lose it. Configure a dead-letter exchange, and set the delivery-limit policy key where a queue needs a different value.

AMQP 1.0 becomes a core protocol

AMQP 1.0 is now always enabled, and the old plugin is a no-op kept so upgrades do not fail. The native implementation validates more strictly: message and delivery annotations must use non-reserved keys starting with x-, and a message must contain a body section. Up to 3.13, the broker interpreted the x-death header when an AMQP 0.9.1 client republished a message. RabbitMQ 4.x does not, so retry frameworks that count attempts through x-death on republish need testing.

Configuration settings removed

The deprecated cluster_formation.randomized_startup_delay_range.min and .max settings were removed. Take them out of your deployment templates, Helm charts and container images first.

How to upgrade to RabbitMQ 4.0

1. Get to the latest 3.13 patch. 4.0 only supports upgrades from 3.13.x. Clusters on 3.12 or older upgrade to 3.13 first.
2. Enable all stable feature flags. 4.0 graduates every feature flag introduced up to 3.13.0. Run rabbitmqctl enable_feature_flag all and confirm with rabbitmqctl list_feature_flags.
3. Remove mirroring. No ha-mode policy should remain.
4. Check the Erlang runtime. RabbitMQ 4.0 and 4.1 require Erlang/OTP 26.2 at minimum and support up to 27.x. See RabbitMQ and Erlang version compatibility.
5. Check client and framework support. Read the documentation for each client library, framework dependency and tool that calls the HTTP API to confirm it has been tested against 4.x.
6. Roll the nodes. Upgrade one node at a time and watch the log on each.

Is RabbitMQ still supported?

Yes, but not 3.13 from the community. Community support for 3.13 ended on 30 September 2024, and the last public patch was 3.13.7. Later 3.13 patches are available only to Broadcom's commercial customers. Public 3.13 builds also run on Erlang/OTP 26, which left Erlang's supported window when OTP 29 shipped in May 2026. The 4.x series is actively maintained.

If the move will take longer than you have

For estates with an ISV product that has not certified 4.x, or hundreds of services declaring their own topology, this checklist is a programme rather than a sprint. OSSeva provides RabbitMQ 3.x extended support with backported CVE fixes for the broker and the Erlang runtime while the migration runs. The RabbitMQ 3.13 end-of-life page sets out the dates.

Frequently asked questions

Can I upgrade from RabbitMQ 3.12 straight to 4.0?

No. RabbitMQ 4.0 only supports upgrades from 3.13.x. Upgrade to the latest 3.13 patch, enable all stable feature flags, then move to 4.0.

What is the default maximum message size in RabbitMQ 4.0?

16 MiB, down from 128 MiB in 3.13. It can be raised with max_message_size in rabbitmq.conf.

Are classic queues deprecated in RabbitMQ 4.0?

No. Only classic queue mirroring was removed. Non-replicated classic queues are still supported and suit temporary, exclusive and reply queues.

Can I turn off the quorum queue delivery limit?

Yes, by setting it to -1, but RabbitMQ does not recommend it. A dead-letter exchange with a sensible limit is the safer design.