Solace Appliance vs Software Broker: When Hardware Still Fits

The Solace appliance is a rack-mounted hardware message broker, sold today as the Solace Event Broker Appliance in two models, the Solace 3560 and Solace 3530 (formerly PubSub+ 3560 and 3530, per the Solace rename table). It runs the same broker as the software and cloud versions. The short answer to “appliance or software?” is that software is the right default for almost every new deployment, including in manufacturing, and the appliance earns its place in a narrow set of cases: latency budgets in tens of microseconds, message rates in the millions per second, or a site policy that rules out shared compute.

This page explains what the appliance is, what Solace claims for it, how the two compare and how to decide. It belongs to the Solace Event Broker overview in the Solace cluster.

What a Solace appliance is

It is where Solace started. The company was founded in Ottawa in 2001 to put messaging into hardware, the way network routers had put IP routing into hardware. The appliance page still describes “hardware-accelerated messaging” and a “rack-mounted messaging platform” with a “chassis-based architecture” (Solace appliance page). The same page also mentions a “Model 3200” in a customs classification note. The current product names in the rename table are the 3560 and 3530.

It is the same broker. Solace states that features are at parity across cloud, software and appliance (Solace IoT page). Topics, queues, Message VPNs, the APIs and the management tools behave the same. Applications do not know which form factor they are connected to.

It is a box you own. It needs rack space, power, cabling into 10 Gigabit Ethernet networks (Solace lists 4×10GE and 8×10GE I/O cards), a hardware support contract and a refresh plan.

Solace appliance performance claims

These figures are from the appliance page, as of October 2026. The page does not say which model they apply to, and they are vendor figures, not independent benchmarks.

Metric	Guaranteed messaging	Direct messaging
Messages per second, point-to-point	620,000	12 million
Messages per second, with fan-out	5.5 million	30 million
Throughput	9.5 Gbps	Up to 80 Gbps
Latency	About 75 µs at 140,000 msg/s	About 20 µs
Storage	Up to 10 billion messages or 6 TB	Not applicable

Solace also states up to 30,000 JMS connections and 200,000 REST or IoT connections, and “99.999% uptime with built-in replication and fast failover”. The hardware carries IEC 62368-1:2018 and CSA C22.2 No. 62368-1:19 safety certification.

What those numbers mean for a plant. A large packaging plant publishing tag changes from a few hundred machines, by exception, might produce thousands to tens of thousands of messages per second at peak (an illustrative order of magnitude, not a measured figure). That is well inside what a software broker handles, which is why performance alone rarely justifies hardware outside capital markets and telecoms.

Solace appliance vs software, compared

The software broker runs on VMware, KVM, Hyper-V and Docker, on AWS, Azure, Google Cloud and OpenStack, and on Kubernetes, PCF/PKS and OpenShift (Solace software page).

Dimension	Appliance	Software (Enterprise Edition)
Runs on	Purpose-built hardware	Your VMs, containers or cloud instances
Published performance	Up to 12M msg/s direct, about 20 µs	No current public benchmark found
Connections	30,000 JMS, 200,000 REST or IoT	Up to 200,000
High availability	“Built-in replication and fast failover” (Solace states)	Three-node group: primary, backup and monitoring node
Scaling	Buy another box	Resize the VM or pod, or add brokers to a mesh
Lead time	Hardware procurement and racking	Deployed on existing infrastructure, once licensed
Operations	Hardware support, firmware, physical access	Your existing VM or Kubernetes practice
Kafka bridging	Not confirmed in the docs	Documented
Fits	Trading, telecoms, policy-driven hardware sites	Almost everything else

When a Solace appliance still makes sense

1. Latency is the product. Capital markets trading and market data distribution are where Solace built its reputation, and where tens of microseconds matter. Solace states that RBC Capital Markets runs more than 50 appliances (RBC story).
2. Rates are in the millions per second. At that scale, a dedicated box can be simpler than a large software cluster.
3. Policy rules out shared compute. Some regulated or air-gapped sites will not put a critical service on a hypervisor they share with other workloads. Solace pitches the appliance for “regulated or air-gapped environments with strict security requirements”.
4. The estate already standardises on it. If a company runs appliances in its data centres, operating knowledge, spares and monitoring are in place, and adding a pair may be the low-risk path.

When software is the better answer

For most enterprises and nearly all plants, the software broker wins on everything except peak performance. It runs on the virtualisation or Kubernetes platform the site already patches, backs up and monitors. It can be resized in an afternoon. A new site can be stood up from a template. And the HA design (a primary, a backup and a small monitoring node, described in the Solace HA docs) is the same everywhere.

In a plant, the software broker typically sits on the level 3 virtualisation cluster or in the industrial DMZ, next to the historian and MES servers. Where it goes relative to the plant MQTT broker and the enterprise is covered on the Solace manufacturing page, and the network side in our guide to OT network segmentation in brownfield plants. If the site runs containers, the Kubernetes and OpenShift page covers the Helm charts and Operator.

Running both: an illustrative pattern

Because the broker is the same everywhere, a company does not have to pick one form factor for the whole estate. An illustrative example: a manufacturer with a trading-style commodity desk already runs a pair of appliances in its primary data centre. Its twelve plants each get a software broker on the local virtualisation cluster, sized to the site. A Solace Cloud service in the region where its analytics platform lives collects what the data team needs. All three are linked by Dynamic Message Routing, so a subscription in the cloud pulls only the matching events out of each plant.

The point of the example is that the form factor follows the site, not the vendor relationship. Each location gets the broker its operating team can actually run, and the event mesh hides the difference from applications.

Where it gets hard

• Model-specific numbers are not public. The appliance page does not tie its figures to the 3560 or the 3530. Ask for figures for your model, message size and guaranteed share, in writing.
• Software performance is not published either. No current Solace benchmark for the software broker was found. Size from a test with your own payloads.
• Kafka bridging is documented for software brokers. If the plan includes in-broker bridging to Kafka, confirm support on the appliance before buying.
• Hardware has a lifecycle. An appliance needs a refresh plan, spares and a support contract that outlasts the project. Ask about end-of-sale and end-of-support policy for the current models.
• Mixed estates add work. Appliances in the data centre and software at the plants is a valid design, but two operating practices, two upgrade paths and two monitoring setups.

---

Related: Solace Event Broker · Standard vs Enterprise · HA and disaster recovery · Solace hub