Solace Platform: Components, the PubSub+ Rename and How They Fit

Solace Platform is the name, since 14 May 2025, for the suite Solace used to sell as the PubSub+ Platform. At its core is the Solace Event Broker, available as a managed cloud service, as software and as a hardware appliance, and those brokers link together into an event mesh that moves events between plants, data centres and clouds. Around the brokers sit Event Portal (design and governance), Solace Insights and distributed tracing (observability), Micro-Integrations (connectors to SaaS, databases and other brokers) and Solace Agent Mesh (AI agents). Solace now markets the whole as a “real-time data platform for the enterprise”.

This page explains what each component does, how they fit, who on a team uses which part, and the full PubSub+ to Solace rename. It sits under the Solace hub, which covers the company and its history.

What Solace Platform is

A broker family first, a platform second. For two decades Solace sold event brokers, starting with hardware appliances for trading floors. The platform layer grew around them: Solace Cloud for managed brokers, Event Portal and Insights for governance and monitoring, and connectors that became Micro-Integrations in December 2024. Agent Mesh followed in 2025. The broker is still the part everything else depends on.

Solace’s own grouping has three layers. The documentation page What Is Solace Platform? describes a core of event brokers (Cloud, Software and Appliance) that “let you scale and federate your system by building an event mesh”, application services that connect things to that mesh (Micro-Integrations, Agent Mesh and developer tools), and platform services for managing it (Event Portal, Insights and distributed tracing). We use the same grouping below, because it matches how the products are bought and run.

The PubSub+ to Solace Platform rename

What happened. On 14 May 2025 Solace announced that “PubSub+” was being removed from its product names or replaced with “Solace”. The products and the technology did not change. The documentation keeps an official name-change table, reproduced here in full with like rows grouped:

Former name	Current name
Solace PubSub+ Platform	Solace Platform
Solace PubSub+ Event Broker	Solace Event Broker
Solace PubSub+ Software Event Broker	Solace Event Broker Software
Solace PubSub+ Standard Edition	Solace Event Broker Standard Edition
Solace PubSub+ Enterprise Edition	Solace Event Broker Enterprise Edition
Solace PubSub+ Appliance	Solace Event Broker Appliance
Solace PubSub+ 3560 and 3530	Solace 3560 and Solace 3530
Solace CLI	Solace Event Broker CLI
PubSub+ Broker Manager	Broker Manager
PubSub+ Cloud	Solace Cloud
PubSub+ Event Broker Service	Solace Event Broker Service
PubSub+ Cloud Console	Solace Cloud Console
PubSub+ Home Cloud	Solace Home Cloud
PubSub+ Mission Control	Mission Control
PubSub+ Mission Control Agent	Mission Control Agent
PubSub+ Insights	Solace Insights
PubSub+ Insights Dashboards and Monitors for Datadog	Solace Insights Dashboards and Monitors for Datadog
PubSub+ Event Portal	Solace Event Portal
PubSub+ Capacity Unit	Platform Capacity Unit
Solace PubSub+ Messaging API for C, .NET, JCSMP, Java RTO, Java, Python, Go, JavaScript and Node.js	Solace Messaging API for the same languages
Solace PubSub+ OpenTelemetry for Solace Java, JCSMP, .NET, Python, Go, JMS, JavaScript and Node.js APIs	OpenTelemetry for Solace (same APIs)
Solace PubSub+ Connector Manager	Solace Micro-Integration Manager
Solace PubSub+ Connectors, and each Connector for a target (Amazon SNS and SQS, Azure Service Bus, Google Pub/Sub, IBM MQ, JMS, MQTT, Oracle AQ, Salesforce, SFTP, Snowflake, TIBCO EMS, and SQL Server, MySQL and PostgreSQL CDC)	Solace Micro-Integrations, and Solace Micro-Integration for each target
Solace PubSub+ Connector for Message Transformations	Solace Transform Processor
Solace PubSub+ Cache	Solace Cache

Older names you will still meet. Before 2018 the software broker was the Solace Message Router or VMR (Virtual Message Router), and the company was Solace Systems. Solace’s docs note that SolAdmin and PubSub+ Monitor, both legacy tools, keep their old names. Many GitHub repositories and container images still carry pubsubplus (the Kubernetes operator is pubsubplus-eventbroker-operator), and SAP’s training material describes advanced event mesh as “based on Solace PubSub+”.

Why it matters in practice. Contracts, purchase orders, firewall rules and runbooks written before mid-2025 use the old names. When you search for a fix, search both. When you renew, check that the quote’s product names map to what you already run, line by line.

The Solace Platform components compared

Component	What it does	Where it runs	Typical first use
Solace Event Broker	Moves events by publish-subscribe, queues and request-reply over SMF, MQTT, AMQP, JMS, REST and WebSocket	Solace Cloud, your VMs, Docker or Kubernetes, or an appliance	A shared backbone for many applications
Event mesh (DMR)	Links brokers so a subscription in one place attracts events from anywhere	Between any brokers	Multi-site or hybrid cloud
Solace Cloud and Mission Control	Creates, upgrades and manages broker services	Solace’s Home Cloud, with an agent beside customer-run brokers	Managed brokers without a broker team
Event Portal	Designs, catalogues and governs events; AsyncAPI import and export	Solace Cloud	An event catalogue across teams
Insights and distributed tracing	Dashboards, alerts and OpenTelemetry traces	Solace Cloud, with export to APM tools	Operating the mesh at scale
Micro-Integrations	Connectors to SaaS, databases, cloud services and other brokers	Cloud-managed or self-managed	Getting ERP or database changes onto the mesh
Agent Mesh	Runs AI agents that talk over the broker	Desktop app, self-hosted or managed cloud (early access)	Agentic AI on live events

The broker features are, by Solace’s account, the same across cloud, software and appliance. The Standard Edition is the exception: it is limited and, in the documentation, not production deployable. Event Broker covers the form factors in depth.

Who uses which part. The platform touches more roles than a single broker does, and the evaluation should include each of them.

Role	Components they work with	The question they bring
Enterprise or integration architect	Event mesh, Event Portal, Micro-Integrations	How do events cross sites, clouds and ERP?
Platform or SRE team	Brokers, Mission Control, Insights, Terraform	How do we deploy, upgrade and watch it?
Application developer	Messaging APIs, Event Portal, AsyncAPI	Which API, which topics, which schema?
OT or controls engineer	MQTT on the broker, plant brokers, topic design	What does it do with my MQTT and Sparkplug traffic?
Data and AI team	Kafka integration, Micro-Integrations, Agent Mesh	How do events reach the lakehouse and the agents?

How the pieces fit: an illustrative example

The following scenario is illustrative, not a customer case. A manufacturer with six plants wants production orders from SAP to reach each plant, and quality results to flow back to a cloud analytics platform.

1. Brokers. Each plant runs a software broker, as a high-availability group on local servers. The head office uses a Solace Cloud service.
2. Mesh. Dynamic message routing links the plant brokers to the cloud service. A plant application subscribes to orders/plant3/> and only that plant’s orders cross the WAN.
3. Integration. A Micro-Integration takes ERP events onto the mesh, and another writes quality results to the analytics platform.
4. Governance. Event Portal holds the catalogue of event types, topics and schemas, so a new team can find “quality result” rather than invent a second one.
5. Operations. Insights and distributed tracing show where a message slowed down or stopped.

Solace Architecture shows where each of these runs and which links carry events rather than management traffic.

Buying it and keeping it current

Packages, not price lists. Solace publishes no dollar prices. The platform services come in three packages, Foundation, Accelerate and Scale, with fixed-subscription or consumption licensing and three support tiers. Editions and Pricing sets out what is in each and what drives a quote.

One long-term release a year. Since June 2025 the broker ships a long-term support (LTS) release each June, supported for two years, plus rolling feature releases every two weeks. As of October 2026 the current LTS is 10.26.0. Releases and LTS covers the calendar and upgrade practice.

What Solace Platform means for a plant

It is an enterprise backbone, not a plant-floor broker. Solace’s own 2026 writing on the unified namespace argues for an event mesh that connects brokers across sites, regions and clouds, not for replacing every line-level broker. In our view that is the right reading. A single site that needs a unified namespace for SCADA and dashboards rarely needs the whole platform; a manufacturer joining many plants to SAP and a cloud data platform might. Solace in manufacturing covers the plant view, and our MQTT guide for manufacturing covers the protocol underneath. Where the decision is part of a wider plan, it belongs in a modernization roadmap.

Limits and open questions

• The free Standard Edition is marked “Production Deployable: No” in the edition comparison, although Solace marketed the free edition as production-ready in 2018. Check the current licence text.
• MQTT has documented deviations. QoS 2 is downgraded to QoS 1, QoS 1 shared subscriptions are downgraded to QoS 0, and retained messages are a Controlled Availability feature (Using MQTT).
• Sparkplug B is not certified. A 2023 community post reported a passing compliance run on broker 10.5, but Solace is not on the Eclipse Sparkplug compatible list.
• Agent Mesh changed underneath its users. It was rewritten in Go in September 2026, and the Python open-source repository is archived.
• No public Enterprise or Agent Mesh pricing. Every serious number comes from a quote.
• Kafka bridging is documented for software brokers only; appliance and cloud support is not stated in the Kafka bridging docs.
• The rename is still settling. Old names persist in repositories, images and partner documents.

How to evaluate Solace Platform

• Which components does our first use case need: brokers only, or brokers plus Event Portal and Insights?
• Which form factor at each site: cloud service, software or appliance, and who operates it?
• Which package carries the governance and observability features we expect, and at what support tier?
• Do our MQTT clients rely on QoS 2, QoS 1 shared subscriptions or retained messages?
• Which roles in the table above have seen a demonstration against their own question?
• Which LTS release will we standardise on, and who owns upgrades?
• What does the quote assume about environments: production, disaster recovery, test and development?
• How will Kafka, SAP and the plant MQTT layer connect, and which mechanism does each use?

Deeper

• Editions and Pricing: broker editions, Solace Cloud service classes and packages, support tiers and cost drivers
• Solace Architecture: data plane and control plane, and where each component runs
• Releases and LTS: the LTS and rolling release model, the calendar and upgrade practice

Back to the Solace hub, or across to Solace Event Broker and the Solace event mesh.