Solace Event Broker: Form Factors, Editions and Selection

The Solace Event Broker is the message broker at the core of the Solace Platform. Applications publish events to hierarchical topics, and the broker delivers each event to every application, queue or remote broker that has asked for it, whichever protocol each one speaks. It comes in three form factors (a managed cloud service, self-managed software and a hardware appliance) and the software comes in two editions. Until May 2025 it was sold as Solace PubSub+ Event Broker, and before 2018 the software version was the Solace Message Router or VMR (Solace rename table).

This page explains what the broker does, how the form factors and editions differ, where the limits are, and how to evaluate one. It sits under the Solace hub, and the four pages in “Deeper” below go into each decision in detail.

What the Solace event broker does

It routes by topic, not by address. A publisher sends an event to a topic such as site1/packaging/line3/filler/state. It does not know or care who is listening. Subscribers register interest with exact topics or wildcards (site1/*/line3/>), and the broker matches every event against every subscription. Adding a new consumer means adding a subscription, not changing the publisher. The messaging model page explains topics, queues and exchange patterns in depth.

It supports two delivery modes on the same topics. Direct messages are delivered at most once, with the lowest latency and no storage. Guaranteed messages are spooled to disk in queues and held until the consumer acknowledges them. A telemetry dashboard can take direct messages while an ERP integration takes the same events through a queue that survives a restart.

It speaks many protocols and converts between them. The broker accepts Solace’s own SMF protocol plus MQTT 3.1.1 and 5.0, AMQP 1.0, JMS, REST and WebSocket, and the product page lists Kafka among its protocols (Solace Event Broker). An MQTT publisher at a line gateway and a JMS consumer in the MES never need to share a protocol.

Why a broker sits between your systems

Without a broker, every integration is a point-to-point connection. The MES polls the historian, the ERP calls the MES, the quality system calls both, and each link has its own protocol, credentials and failure mode. Ten systems that all need each other’s data means up to 45 links, and each one breaks a little differently when a server is patched.

A broker turns that into a hub of subscriptions. Each system connects once, publishes what it knows and subscribes to what it needs. When the quality system is down for an upgrade, its queue fills and drains when it returns; the filler does not notice. That is the property plants care about: a slow or failed consumer stops affecting the producer.

An illustrative case. A plant publishes a production confirmation each time a pallet is wrapped. Today the line PLC’s gateway calls the ERP’s web service directly, and when the ERP is in its Sunday maintenance window, confirmations are lost and someone keys them in on Monday. With a broker, the gateway publishes to site1/packaging/line3/confirmation, the ERP integration reads from a guaranteed queue subscribed to that topic, and the weekend backlog drains in order when the ERP returns. A dashboard and a quality application can subscribe to the same topic later without anyone touching the gateway.

The trade-off is that the broker becomes critical infrastructure. If it stops, everything that depends on it stops. That is why the form factor, the edition and the high availability design matter more than the feature list.

The three Solace event broker form factors

Solace sells the same broker in three packages and states that features are at parity across them (Solace IoT page). The real differences are who operates it, where it runs and how it scales.

	Solace Cloud	Event Broker Software	Event Broker Appliance
Who runs it	Solace (or Solace’s control plane on your Kubernetes)	You	You
Where it runs	AWS, Azure, Google Cloud and others; or your own cluster in a Customer-Controlled Region	VMware, KVM, Hyper-V, Docker, public cloud VMs, Kubernetes, OpenShift	Your rack, in a data centre or at the edge
High availability	HA by default, standalone optional	You build the three-node HA group	Built-in redundancy and replication
Scale	Service classes from 250 to 100,000 connections, and 200,000 on request (as of October 2026)	Up to 200,000 connections (Enterprise)	Up to 30,000 JMS and 200,000 REST or IoT connections (Solace states)
Typical fit	Teams that do not want to operate brokers	Plants and data centres with platform teams, air gaps, or Kubernetes	Ultra-low latency, regulated sites, very high message rates

Sources: software page, appliance page, Solace Cloud pricing, deployment ownership models.

The cloud service is covered on the Solace Cloud page. Software versus hardware is a decision in its own right for a small number of sites, and it has its own page: software vs appliance.

Editions: Standard and Enterprise

The software broker comes in a free Standard Edition and a commercial Enterprise Edition, plus a 90-day Enterprise evaluation key (Solace docs).

	Standard	Enterprise
Price	Free	Not published
Client connections	Up to 1,000	Up to 200,000
Message rate	10,000 messages/s limit	Unthrottled
Message VPNs	1	5
Disaster recovery (replication)	No	Yes
Production deployable (docs)	No	Yes

The last row is the one to read twice. Solace launched the free edition in 2018 as “production-ready”, and the current documentation says the opposite. The Standard vs Enterprise page sets out both sources and what we would ask Solace before relying on Standard anywhere that matters. Commercial terms for the whole platform are on the editions and pricing page.

What every Solace event broker includes

Solace lists these features for all form factors (product page):

• Multi-protocol support: AMQP, Kafka, MQTT, REST, WebSocket, alongside SMF and JMS
• Smart topics with wildcards, filtered at the broker
• All exchange patterns: publish-subscribe, point-to-point and request-reply
• Queue types including partitioned and last value queues
• Event caching and message replay
• Broker-native OpenTelemetry distributed tracing, dashboards and alerts
• Micro-integrations to SaaS, databases and other brokers

Brokers link into an event mesh through Dynamic Message Routing, so a broker in a plant and a broker in the cloud share subscriptions. The protocols and APIs page covers what each protocol supports in practice.

How to select a Solace event broker

1. Decide who operates it. If you have no platform team that already runs stateful services, start with Solace Cloud and look at Customer-Controlled Regions only if data must stay on your infrastructure.
2. Decide where it must run. A plant with an air gap, or a site whose WAN cannot be a dependency, needs a broker on site: software on a VM or a Kubernetes cluster, or an appliance.
3. Size it from real numbers. Count connections, peak messages per second, the share that must be guaranteed and the spool needed to ride through a consumer outage. Those numbers decide the edition and the cloud service class.
4. Decide your recovery targets first. High availability within a site and replication between sites are separate features, and replication needs Enterprise. See HA and disaster recovery.
5. Plan the release track. Since June 2025 Solace ships long-term support releases (10.26.0 as of October 2026) and biweekly rolling releases. The releases and LTS page explains the choice.

Limits and open questions

• Standard Edition is marked “not production deployable” in the docs, while the 2018 launch called it production-ready. Check the current licence text.
• MQTT deviations: QoS 2 is downgraded to QoS 1, QoS 1 shared subscriptions are downgraded to QoS 0, and retained messages are in controlled availability (Using MQTT). See the Solace MQTT page.
• Sparkplug B: a community test against broker 10.5 passed the Eclipse TCK in 2023, but Solace is not on the Eclipse compatible list (Eclipse list).
• Kafka bridging is documented for software brokers only. Appliance and cloud support is not confirmed. See Kafka integration.
• No public Enterprise pricing. Budgeting needs a quote.
• Appliance figures are not tied to a model. The appliance page publishes performance numbers without saying whether they apply to the 3560 or the 3530.
• No published failover time for an HA pair in the documentation we reviewed.

How to evaluate it

• Which form factor fits our operating model, and who carries the pager for it?
• What are our peak connections, peak message rate and guaranteed share, per site?
• Do any of our MQTT clients depend on QoS 2, retained messages or Sparkplug host state?
• What failover time does Solace commit to for our deployment, and how do clients reconnect?
• Do we need replication between sites, and therefore Enterprise or a cloud tier that includes it?
• Which release track will we run, and how often can we take an upgrade window?
• Is our Kafka integration plan valid for the form factor we chose?
• What does the quote include: support level, Event Portal, Insights, Mesh Manager?

For a plant, the broker decision is part of a wider integration design that includes the plant MQTT layer and the ISA-95 placement. An independent IT/OT integration review can test those answers before a purchase order is signed. Vendor-neutral context is on the event broker comparison.

Deeper

• Software vs Appliance: what the hardware still offers, the published throughput claims and a decision tree
• Standard vs Enterprise: the full limits table and the production deployable question, with both sources
• Kubernetes and OpenShift: the Helm charts, the Operator, persistence and HA on a cluster
• High Availability and Disaster Recovery: HA groups, the monitoring node, sync and async replication, and RPO and RTO

Back to the Solace hub, or across to the messaging model, which explains what the broker does with each message.