meshIQ benchmark finds no single messaging broker wins

meshIQ has published a benchmarking report comparing Apache ActiveMQ, Apache Artemis and RabbitMQ. The study found that no single broker led across every tested workload.

The 75-page report examines how the three open-source messaging brokers performed across different combinations of protocol, workload pattern, message size, concurrency and batching. It focuses on durable messaging tests across JMS, native and AMQP 1.0 paths, with power-safe persistence and message reconciliation treated as baseline requirements.

The aim was to measure performance without reducing delivery assurance, which matters in sectors where missed messages can interrupt business processes. Each test counted a message only after it had been safely stored and verified that sent messages were received.

Workload split

The findings show that Apache Artemis led several durable workloads, particularly demanding high-concurrency tests. In one 1KB high-concurrency JMS test with batch size set to one, Artemis delivered nearly 14 times the throughput of ActiveMQ.

Artemis also scaled most strongly in durable publish-and-subscribe fan-out workloads and led the durable comparison for large-message, high-batch scenarios.

Apache ActiveMQ, by contrast, performed best in batched and large-message workloads. When batch size increased to 1,000, durable throughput rose above 34,000 messages per second. ActiveMQ also recorded the lowest request-reply latency in the 100KB test.

RabbitMQ stood out in low-concurrency and native-protocol tests. It led low-concurrency point-to-point performance and the AMQP 1.0 batch-equals-one tests, while native request-reply latency reached about 1.23 milliseconds at 1KB, compared with roughly 105 milliseconds through JMS.

Testing depth

meshIQ narrowed the scope of the latest benchmark from a broader seven-platform review in its earlier study to three open-source brokers, while expanding the number of tests applied to each. The report separates protocol paths rather than grouping them together, meaning the results reflect differences in client choice, transaction design and workload architecture as well as broker behaviour.

meshIQ presents the report as a tool for architects, platform engineering teams, operations staff and technology leaders weighing open-source messaging platforms against practical deployment needs rather than general claims about speed.

Messaging brokers sit at the centre of many transaction-heavy systems, where applications exchange data for payments, claims processing, logistics updates and other operational tasks. In these environments, throughput is only one measure; message durability, protocol support and latency can shape platform choices as much as raw speed.

Daniel Rigos, DevOps team lead at meshIQ and author of the report, said the test design aimed to keep delivery assurance constant across all three brokers.

"In regulated industries such as financial services and healthcare, a lost or unrecoverable message can disrupt sensitive information such as payments, claims, or patient workflows, so delivery failure cannot be treated as an acceptable tradeoff for speed or cost," Rigos said.

"For each broker in our analysis, a message counted only after it was safely stored, and each test verified that the messages sent were received. With delivery assurance held constant, performance differences could be traced to architecture and workload rather than to a platform gaining speed by relaxing durability."

Selection pressures

The report arrives as many companies reassess middleware estates spanning open-source software, commercial tools, cloud services and older messaging systems. That mix can complicate decisions because benchmark results often vary sharply depending on message size, persistence requirements, concurrency levels and protocol choices.

By isolating JMS, native and AMQP 1.0 tests, the study highlights a long-standing issue for buyers and engineering teams: a broker that performs strongly in one pattern may not deliver the same result in another. The findings suggest selection decisions should be tied to application design and operating conditions rather than headline throughput figures.

Navdeep Sidhu, Chief Executive Officer at meshIQ, said broker selection was only one part of running messaging systems in production.

"Open-source messaging gives enterprises greater architectural choice, but making an initial selection is only part of the challenge," Sidhu said.

"Organisations also require the expertise and operational visibility to monitor broker and queue behavior, trace transactions, identify root causes, and tune environments as applications and infrastructure evolve. The goal isn't to simply deploy a broker, but to keep the critical business services depending on it reliable, observable, and resilient over time."