RabbitMQ in Production 2026: What 22 Assessed Estates Actually Run

The counts below are the series each estate was running when it was observed; where an estate was observed twice, years apart, both observations are kept because each is a real production state. Community end-of-support dates are from the RabbitMQ release information page as of 15 September 2026. Commercial support runs longer for licensed customers: 3.13 to 31 December 2029 and 4.2 to 30 June 2030.

Two different rates matter. The first is how many estates were already out of community support at the moment AceMQ first saw them: 11 of 16, or 69%. That is the number that describes what a consultant walks into. The second is how many are past it today, September 2026, given that 4.2 left community support on 31 July 2026: 15 of 16, or 94%. The gap between the two is mostly estates that were on a current series when assessed and have since been overtaken by the calendar, which is the normal condition of a RabbitMQ estate that is not on a maintenance cadence. Only the estates on 4.3 are on a series with community support still ahead of them, and that support ends on 30 November 2026.

The Erlang runtime was recorded for 6 estates. The pairings are the ones the compatibility matrix predicts, which is the point: 3.13 cannot run above Erlang 26.2, and Erlang 26 is end of life, so a 3.13 estate that patches its runtime has nowhere to go without a broker upgrade. Two of the recorded estates were running mixed Erlang versions across nodes at the time, which the project explicitly warns against and which produced a broken CLI on one of them.

Node counts were recorded for 8 clusters. Three is the modal size, and it is the right one for a quorum-based system: it survives one node loss and cannot split evenly. 3 of the 8 ran an even count, two or four, which either cannot tolerate any loss or can partition into halves with no majority; one of the four-node estates had been assessed precisely because of that. Platforms: 2 of the 22 estates on Windows Server, 1 of the 9 with a recorded platform on Kubernetes, the remainder on Linux virtual machines. Windows is over-represented relative to the project's own recommendations and under-represented in public tooling, and it is where the CLI, antivirus and service-account failures in AceMQ's records concentrate.

Each estate entered the dataset through one kind of engagement. The mix is a rough proxy for what brings a RabbitMQ estate to outside help: assessment and support most often, then licensing, then a planned upgrade.

Sources. AceMQ engagement delivery reports, technical assessment documents, discovery and renewal call records, and support correspondence, 2019 to 15 September 2026. Every value was read from a document or transcript; nothing was inferred. Where a document gave a version range, the lower bound was used.

Anonymisation. No estate is named, and industries are given at a level that does not identify a customer. Node counts and versions are reported exactly because they do not identify anyone.

Limits. 22 estates is a sample of the environments AceMQ has worked in, not of RabbitMQ users at large, and it is biased towards estates that needed help. A team running a current 4.3 cluster on a maintenance cadence rarely calls a consultancy, so this dataset almost certainly overstates how old the general installed base is. Treat the rates as what an engineer inheriting a RabbitMQ estate should expect to find, not as a market share. Fields not recorded in the source are left blank rather than estimated, which is why the Erlang and node-count tables are smaller than the version table. The dataset will be extended as further engagements are documented.