Event Broker Comparison for Manufacturers

Event broker comparison on the same dimensions: Solace, Kafka and Confluent, IBM MQ, HiveMQ, EMQX, RabbitMQ, Pulsar, NATS and the cloud services.

This event broker comparison puts nine products and the three major clouds on the same dimensions: delivery model, protocols, deployment, licence and ownership, how each connects sites, and Sparkplug status. The short answer is that no single broker wins. MQTT brokers (HiveMQ, EMQX) suit the plant floor, enterprise messaging (IBM MQ, RabbitMQ) suits transactions and application integration, streaming platforms (Kafka and Confluent, Pulsar) suit analytics and replay, and multi-protocol meshes (Solace, NATS) suit many sites and mixed protocols. The question is which one fits each layer of your architecture.

Gartner’s Market Guide for Event Brokers covers 20 vendors and is a guide, not a ranking; there is no Gartner Magic Quadrant for this market (Gartner, via Solace). Facts below are as of October 2026 and come from each vendor’s or project’s own documentation unless linked otherwise. This page is part of our event-driven architecture guide.

The dimensions we compare on

Delivery model: does the broker push and delete on delivery (messaging), or keep a log consumers pull and replay (streaming)?
Protocols: which clients can connect natively, without a separate gateway?
Deployment: hardware, software, Kubernetes, managed cloud, edge footprint.
Licence and owner: who controls the roadmap, and what changed recently.
Multi-site: how events cross plants, data centres and clouds.
Sparkplug status: whether the broker is on the Eclipse compatible list (Eclipse).

Event broker comparison: what each product is

Product	Delivery model	Native protocols	Deployment	Licence and owner
Solace (Solace Platform, formerly PubSub+)	Messaging: topics and queues, with replay	SMF, MQTT 3.1.1 and 5, AMQP 1.0, JMS, REST, WebSocket; Kafka bridging	Hardware appliance, software, Solace Cloud	Commercial, private company; free Standard Edition documented as not production deployable
Apache Kafka and Confluent	Streaming: partitioned, replicated log	Kafka protocol; MQTT through connectors or a proxy	Self-managed; Confluent Platform, Confluent Cloud, WarpStream (bring your own cloud)	Kafka is Apache 2.0; Confluent is owned by IBM since March 2026 (IBM)
IBM MQ	Messaging: queue manager, also publish and subscribe	MQI, JMS, AMQP 1.0, MQTT (telemetry), REST	z/OS, distributed, containers, IBM MQ SaaS	Commercial, IBM
HiveMQ	Messaging: MQTT broker	MQTT 3.1, 3.1.1 and 5	Self-managed, HiveMQ Cloud, HiveMQ Edge	Commercial, with an open-source Community Edition
EMQX	Messaging: MQTT broker with a rule engine	MQTT 3.1, 3.1.1 and 5, MQTT over QUIC	Self-managed, EMQX Cloud, NanoMQ at the edge	Business Source License 1.1 from v5.9, free for single-node production (EMQ)
RabbitMQ	Messaging: queues and exchanges, plus Streams	AMQP 0-9-1, AMQP 1.0, MQTT, STOMP	Self-managed, many hosted offerings, Amazon MQ	MPL 2.0 open source; commercial Tanzu RabbitMQ from Broadcom
Apache Pulsar	Both: queues and streams, tiered storage	Pulsar protocol; Kafka and MQTT through protocol handlers	Self-managed, StreamNative Cloud	Apache 2.0; StreamNative is the main commercial vendor
NATS	Messaging, with JetStream persistence	NATS, MQTT 3.1.1, WebSocket	Anywhere, very small footprint; leaf nodes at the edge	Apache 2.0, CNCF project; Synadia is the commercial steward
AWS	IoT Core (messaging), MSK (streaming), EventBridge (event bus)	MQTT 3.1.1 and 5 on IoT Core, without QoS 2; Kafka on MSK	AWS regions only	Managed services
Microsoft Azure	Event Grid (messaging, including an MQTT broker), Event Hubs (streaming)	MQTT 3.1.1 and 5 on Event Grid; AMQP and a Kafka endpoint on Event Hubs	Azure regions; Azure IoT Operations for edge Kubernetes	Managed services
Google Cloud	Pub/Sub (messaging), Managed Service for Apache Kafka (streaming)	gRPC and REST on Pub/Sub, no MQTT; Kafka	Google Cloud regions	Managed services

Where each event broker fits

Product	Multi-site mechanism	On the Sparkplug list	Fits best	Watch for
Solace	Dynamic Message Routing between brokers (an event mesh)	No; a 2023 community test reported a pass	Multi-site, multi-protocol enterprise backbone; SAP estates via SAP’s advanced event mesh	MQTT QoS 2 delivered as QoS 1, QoS 1 shared subscriptions as QoS 0, retained messages in controlled availability (Solace); no public enterprise price
Kafka and Confluent	MirrorMaker 2; Confluent Cluster Linking	Not applicable	Analytics, data platforms, long retention, stream processing	Not a device protocol; operational effort; product direction under IBM still emerging
IBM MQ	Channels and clusters between queue managers; Native HA cross-region replication	Not applicable	Transactions, mainframe and ERP integration, regulated messaging	Fan-out to large device fleets; licence cost
HiveMQ	Clustering; bridging between brokers	Yes (Community and Professional)	Plant and enterprise MQTT, the unified namespace, Sparkplug hosts	Non-MQTT consumers need extensions or a bridge
EMQX	Clustering; bridging and data integrations	EMQX no; NanoMQ yes	Very large device connection counts, rule-based routing to databases	Licence terms for multi-node production
RabbitMQ	Federation and shovel	No	Application task queues, developer familiarity	Community support narrowed in 2024 (RabbitMQ); device scale
Apache Pulsar	Built-in geo-replication	No	Multi-tenant platforms needing both queues and streams	Smaller ecosystem; more moving parts to operate
NATS	Clusters, superclusters through gateways, leaf nodes	No	Lightweight edge-to-cloud messaging, Kubernetes-native teams	MQTT 3.1.1 only; no JMS or AMQP
AWS, Azure, Google Cloud	Regional services; cross-region varies by service	No	Single-cloud estates that want no broker operations	No presence inside the plant without an edge product; feature gaps against the MQTT standard

Read the map by layer, not by winner. A multi-site manufacturer typically picks one product from the lower left for the plant, one from the middle or lower right for the enterprise backbone, and one from the top right for the data platform.

Ownership and licence changes since 2024

The market has shifted under buyers’ feet, and a broker is a ten-year decision. Four changes matter:

IBM bought Confluent. Announced December 2025, closed March 2026. IBM now owns IBM MQ, IBM Event Streams and Confluent. Customers should watch for product and pricing changes; none should be assumed yet.
RabbitMQ community support narrowed. Since June 2024, Broadcom restricts community support and patches for older releases; the open-source licence is unchanged.
EMQX moved to the Business Source License. From v5.9 the open-source and enterprise editions merged under BSL 1.1, which allows free production use of a single node and converts to Apache 2.0 after a change date.
NATS stayed open. In 2025 Synadia sought to withdraw NATS from the CNCF and relicense it, then agreed to transfer the trademark to the Linux Foundation and keep Apache 2.0 (CNCF).

The lesson for a buyer is to separate the protocol from the product. A plant that standardises on MQTT 5 and documented topics can change brokers far more easily than one built on a vendor’s proprietary features.

Shortlists by use case

Use case	Typical shortlist	Why
Single-site unified namespace	HiveMQ, EMQX, Mosquitto, a broker inside Ignition or HighByte	MQTT and Sparkplug at plant scale, run by a controls team
Multi-site plant-to-enterprise backbone	Solace, HiveMQ (enterprise), Kafka or Confluent, NATS	Buffering across the WAN, routing between many sites
ERP, MES and quality transactions	IBM MQ, Solace, RabbitMQ	Queues, guaranteed delivery, JMS and AMQP
Analytics, data lake, machine learning	Kafka or Confluent, Pulsar, MSK, Event Hubs	Retention, replay, stream processing
Single-cloud estate	AWS IoT Core and MSK, Azure Event Grid and Event Hubs, Google Pub/Sub	No broker to operate

Hammer, pliers, screwdriver, hex keys and tape measure laid on a wooden slatted bench — Nobody asks whether a hammer beats a screwdriver. A broker comparison is only useful once each layer of the architecture has a defined job.

An illustrative example. A food manufacturer with eight plants already runs Ignition with an MQTT broker at each site, SAP for ERP and a cloud lakehouse. A sensible shortlist keeps the plant brokers, evaluates an enterprise backbone (an event mesh, or Kafka with bridges) for the ERP and quality flows, and leaves the lakehouse on the cloud streaming service the data team already operates. The comparison that matters is the backbone, and it should be scored on the dimensions above with the plant’s real WAN, security zones and support model.

Limits and open questions

Feature lists hide conformance gaps. Several brokers and cloud services accept MQTT features they then downgrade. Read conformance pages, not data sheets.
Performance claims are not comparable. Vendors benchmark different message sizes, guarantees and hardware. Test your own payloads and failure cases.
Pricing is rarely public. Most commercial brokers price on request; cloud services price on usage that is hard to estimate before a pilot.
Sparkplug listing is self-submitted. Absence from the Eclipse list means the vendor has not listed, not necessarily that it fails. Presence means a test was passed at a point in time.
Ownership is moving. The IBM and Confluent combination is new, and its effect on both product lines is not yet public.

How to evaluate an event broker

Which layer is this broker for: plant, enterprise backbone or data platform?
Which protocols must connect natively, and are any features downgraded?
How does it behave when a consumer is slow, a node fails or the WAN drops for four hours?
Who will run it on night shift, and what support does the vendor offer at a plant?
How does it connect to the other two layers?
What does it cost at today’s scale and at three times that, including support?
What is the exit path if the owner or licence changes again?

An independent comparison against your own requirements is the kind of decision an owner’s engineer supports; for MES-adjacent choices our MES selection work covers the same ground.

Deeper

There are no child pages under this guide yet. These go further:

Solace alternatives: the landscape from one vendor’s position
Solace vs HiveMQ and Solace vs IBM MQ: two head-to-head comparisons
UNS Broker: the plant layer of this comparison, in detail
What Is an Event Mesh: the multi-site mechanisms behind the table

Back to the event-driven architecture hub.

Frequently asked questions

What is the best event broker?

There is no single best event broker, because the products are built for different jobs. MQTT brokers suit devices and the plant floor, enterprise messaging suits transactions and ERP, streaming platforms suit analytics and replay, and multi-protocol meshes suit many sites. Gartner advises against using one technology for every use case, and most large manufacturers run two or three.

What is the difference between an event broker and a message broker?

In practice the terms overlap. Message broker is the older term for middleware that routes and queues messages between applications. Event broker is the newer term, used by analysts and vendors for the same category plus streaming platforms that keep event history. When comparing products, ask about the delivery model and retention rather than the label.

Which event brokers are on the Eclipse Sparkplug compatible list?

As of October 2026, the Eclipse Sparkplug compatible software list includes HiveMQ (Community and Professional editions), NanoMQ from EMQ, and Cirrus Link Chariot as brokers. EMQX itself, Solace, Mosquitto and the cloud MQTT services are not listed, although several can carry Sparkplug traffic as plain MQTT. Check the live list before relying on this.

Is Confluent still independent?

No. IBM announced its agreement to acquire Confluent in December 2025, and the acquisition closed in March 2026. IBM now owns IBM MQ, IBM Event Streams and Confluent, which makes it the broadest single vendor across enterprise messaging and event streaming. Apache Kafka itself remains an Apache Software Foundation project.

Which event broker should a manufacturer start with?

Start from the first use case and who will run the broker. A single plant building a unified namespace usually starts with an MQTT broker its controls team can operate. A multi-site programme with ERP and quality flows needs an enterprise backbone. A data platform team usually brings Kafka or a cloud streaming service. Pick per layer, and plan the bridges.

Event Broker Comparison: Solace, Kafka, IBM MQ, HiveMQ, EMQX, RabbitMQ, Pulsar, NATS and Cloud