Should I upgrade to RabbitMQ 3.13 Khepri vs Mnesia Upgrade Path to 4.0 in now?
Decide the supported path from RabbitMQ 3.13 to 4.x based on whether the 3.13 cluster stayed on Mnesia or enabled Khepri.
Blockers
- RabbitMQ officially supports direct upgrades from 3.13.x to 4.0.x.
- RabbitMQ officially supports direct upgrades from 3.13.x to 4.1.x.
- RabbitMQ officially supports direct upgrades from 3.13.x to 4.2.x.
- Official upgrade guidance requires all stable feature flags to be enabled before upgrading.
- A 3.13 node is considered to have enabled Khepri when the khepri_db feature flag is enabled.
- RabbitMQ states 3.13.x clusters with Khepri enabled cannot be upgraded to 4.x in place because major Khepri changes introduced incompatibilities between 3.13 and 4.x.
Who this is for
- enterprise
- high-scale
- low-ops
Candidates
Upgrade 3.13 Mnesia-backed clusters directly to RabbitMQ 4.x, keep Mnesia first
As of 2026-04-02, RabbitMQ officially supports direct upgrades from 3.13.x to 4.0.x, 4.1.x, and 4.2.x. RabbitMQ 4.0 fully supports Khepri, but Mnesia remains supported, and deployments upgraded to 4.2.x continue using Mnesia until an administrator explicitly enables Khepri. Official upgrade guidance also requires all stable feature flags to be enabled before upgrading. This is the lowest-risk path for clusters that never enabled Khepri on 3.13.
When to choose
Use this when the current 3.13 cluster still uses Mnesia and the goal is a supported in-place upgrade with the fewest moving parts.
Tradeoffs
Pros: officially supported direct path from 3.13.x to 4.x, no metadata-backend migration during the major-version jump, and Mnesia remains usable after upgrade. Cons: you defer Khepri adoption to a later change window, and you still need to validate feature flags, Erlang compatibility, and plugin compatibility.
Cautions
Do not assume that Khepri-related log lines mean the cluster is Khepri-backed; RabbitMQ documents that Khepri is initialized even when Mnesia remains the active backend. Check official docs for exact target patch release and Erlang version requirements before execution.
Do not in-place upgrade 3.13 clusters that enabled Khepri; use blue-green migration to a fresh 4.x cluster
As of 2026-04-02, RabbitMQ explicitly states that 3.13.x clusters with Khepri enabled cannot be upgraded to 4.x in place because major Khepri changes introduced incompatibilities between 3.13 and 4.x. RabbitMQ also states that once Khepri migration is performed, going back to Mnesia is unsupported. The documented alternative is a blue-green deployment that moves definitions and workloads to a new 4.x cluster instead of trying to roll the old cluster forward.
When to choose
Use this when any 3.13 node actually enabled the `khepri_db` feature flag and you need a supported path to RabbitMQ 4.x.
Tradeoffs
Pros: the only documented supported path for 3.13 clusters that already enabled Khepri, and it avoids relying on an unsupported return to Mnesia. Cons: requires parallel cluster operation, migration orchestration, cutover planning, and validation of exported definitions and client failover behavior.
Cautions
The blocker is backend state, not just version number. If Khepri was enabled on 3.13, RabbitMQ documents that disabling Khepri and returning that cluster to Mnesia is unsupported, so plan for fresh-cluster migration rather than staged rollback.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to RabbitMQ 3.13 Khepri vs Mnesia Upgrade Path to 4.0 in now?"