From Solace to NATS: One Platform for Messaging, Streaming, and the Edge

Solace has spent two decades building event-driven messaging. PubSub+ pioneered the event mesh idea, and it earned a durable position in capital markets, logistics, and manufacturing. Architects who bet on Solace got a serious product built by serious people.

Architectures have moved since then. The workloads that used to live on a message broker now share space with streaming pipelines, edge devices, Kubernetes control planes, and AI agents that need a common fabric to talk over. Teams are re-examining whether a commercial event broker still belongs at the center of that stack, or whether the center should be something lighter, more open, and broader in scope.

That is the question this post answers. The short version: NATS speaks the same subject-based language as Solace, so the migration is more concrete than most middleware comparisons ever get. And once you migrate, several products you were running around Solace collapse into a single open source platform.

Here is the piece of the story that makes the rest of it tangible. Solace subjects look like this:

1
orders/state/city/store

NATS subjects look like this:

1
orders.state.city.store

Same hierarchy. Same wildcard behavior. Different delimiter. If you can read one, you can read the other.

What Solace and NATS have in common

Before looking at where the two diverge, it is worth mapping the shared ground, because it is substantial.

Subject-based messaging with hierarchies and wildcards. Both systems route messages by subject, not by queue name or topic ID. Both support hierarchical namespaces and multi-level wildcards. Solace uses / as its delimiter and * and > for wildcards. NATS uses . as its delimiter and * and > for wildcards. The mental model is the same.

Core interaction patterns. Publish/subscribe, point-to-point, and request-reply are first-class in both platforms. Application logic written around these patterns carries over. What changes is the client library and the syntax, not the design.

Event mesh as a concept. Solace’s Dynamic Message Routing propagates subscription interest across a network of brokers so that a publisher in one region can reach a subscriber in another without explicit bridging. NATS solves the same problem through subject-interest propagation across clusters and superclusters, and refers to the resulting topology as an event fabric. Different algorithms, same architectural outcome.

Native MQTT and WebSockets. Both platforms terminate MQTT and WebSocket connections directly, without a sidecar gateway, which matters for browser clients and IoT devices.

A management plane for hybrid deployments. Solace has PubSub+ Mission Control and its cloud console. Synadia offers Synadia Control Plane for managing NATS deployments across on-prem, cloud, and edge.

Low-latency, high-volume design. Both are engineered for the kind of throughput and tail-latency profile that financial and industrial workloads require.

That is a genuine amount of shared surface. It is why migrations from Solace to NATS tend to be less painful than migrations between messaging systems that do not share this model.

Where NATS goes further

Native streaming

Solace provides guaranteed delivery through queue-backed persistence. That covers durable messaging well. It does not cover streaming: log-structured retention, replay from arbitrary offsets, consumer state managed by the broker, event sourcing patterns. Teams that want those capabilities alongside Solace typically add Kafka, and then operate two messaging systems side by side with two security models, two operational playbooks, and two sets of client libraries.

NATS includes streaming natively through JetStream. Streams sit on the same subjects as ephemeral messaging, share the same security model, and are managed through the same tooling. A consumer can be a pub/sub subscriber today and a durable, replayable stream consumer tomorrow without changing brokers.

One platform instead of four products

A NATS server is a single lightweight binary that provides messaging, streaming, a distributed key-value store, and an object store. The KV store is useful for configuration, feature flags, and session state. The object store handles larger payloads that do not belong on a message bus.

The equivalent capability set around a pure messaging broker generally means adding a caching or KV layer (Redis, etcd), a separate object store (S3-compatible or otherwise), and a streaming platform (Kafka or similar). Each has its own licensing, its own operator burden, its own upgrade cadence, and its own hiring profile.

The TCO argument here is structural, not a price sheet. Fewer systems to license. Fewer systems to run. Fewer systems to secure. Fewer skills to hire for. That is the shape of the savings.

Simpler scaling and high availability

Solace production deployments typically pair brokers in active-passive configurations, with a monitoring node to arbitrate failover. The event mesh scales by connecting bounded DMR clusters together as demand grows.

NATS clusters are full meshes of active nodes. There is no standby broker sitting idle. JetStream uses RAFT consensus for stream replication, so durability guarantees are explicit and testable. Superclusters connect clusters across regions using gateway connections that are part of the same server binary, not a separate component you deploy and operate.

The practical effect is fewer moving parts. No standby hardware. No separate router tier. Adding capacity means adding nodes to the mesh.

A real edge story

This is the differentiator that hits hardest for Solace shops evaluating alternatives.

Solace’s edge approach centers on clients connecting to brokers, where the brokers themselves live in cloud regions or hyperscaler edge infrastructure. That works when connectivity is good and the edge is really just “close to the user.”

NATS leaf nodes run the same server binary out at the actual edge: on a vehicle, in a retail location, on a factory line, inside a device. Leaf nodes provide local pub/sub and request-reply even when disconnected from the core, buffer messages during outages, and forward when connectivity returns. Security domains isolate edge tenancy from cloud tenancy, so a compromised site does not compromise the fabric.

For fleets, plants, depots, and connected products, that is a category difference. You are not extending the reach of a cloud broker. You are running the broker where the events happen.

Open source and ecosystem

NATS is open source under the Apache 2.0 license and part of the CNCF ecosystem. There are mature clients for Go, Rust, Python, Java, C#, JavaScript, C, and others, plus a large practitioner community that talks openly about deployments, patterns, and problems.

Solace is a commercial platform. Its skills pool is real but smaller and largely confined to enterprises that have licensed it.

The practical consequences show up in hiring and onboarding. Engineers can install NATS locally, embed it in tests, or spin it up in a container without a procurement conversation. Platforms and products increasingly embed NATS internally as their control plane or data bus, which means new engineers often arrive already familiar with it.

On security, NATS supports a decentralized model built around operators, accounts, and users signed with NKeys and JWTs. Accounts provide strong multi-tenant isolation with explicit import and export of subjects between tenants. For teams that prefer a centralized model, Auth Callout delegates authentication to an existing identity provider. Content-level policy enforcement is available through Synadia Protect. Solace’s ACL model is broker-scoped and works well within that scope; the NATS account model is designed for tenancy that spans a mesh.

What a Solace to NATS migration involves

Migrations tend to break down into five workstreams. Most teams tackle them project by project rather than as a big-bang cutover, and the two systems can coexist during the transition through bridging.

1. Convert subject nomenclature. Replace / with . and confirm wildcard usage carries over. Hierarchy and interest semantics are preserved. This is mechanical and easy to script.

2. Update application client code. Swap Solace client libraries for NATS clients in each service. The interaction patterns (pub/sub, point-to-point, request-reply) map directly, so the changes are largely at the API surface. Request-reply in NATS uses ephemeral inboxes; queue groups replace exclusive consumer groups; durable consumers on JetStream cover the guaranteed-delivery use cases.

3. Map the security model. Decide between centralized authentication (Auth Callout against your existing IdP), the decentralized operator model (accounts, users, NKeys, JWTs), or a hybrid where different environments use different approaches. Most enterprises land on the operator model for production because it aligns with multi-tenant, multi-region deployments.

4. Re-platform the mesh. DMR clusters become NATS clusters. Cross-region bridging becomes a supercluster with gateway connections. Edge sites that used to be broker clients become leaf nodes. This is where the operational simplification is most visible: what was a tiered deployment of appliances and routers becomes a mesh of a single binary.

5. Transition management tooling. Move day-two operations onto Synadia Platform, Insights, and Protect. Inventory the connectors and integrations you rely on and plan how they map to the Synadia connector framework or to direct client integrations.

One honest caveat. Teams that make heavy use of Solace Event Portal as a design-time catalog should plan for that function separately. NATS is a runtime platform. It does not ship a bundled event design environment. The open standard here is AsyncAPI, which many teams pair with Control Plane’s workload deployment for the full lifecycle. If Event Portal is central to how your organization designs events today, factor that into your migration plan rather than assuming a drop-in replacement.

Where this lands by vertical

Financial services. Solace’s historical stronghold. NATS preserves the low-latency subject-based semantics that trading and market data workloads depend on. JetStream adds durable streaming for trade lifecycle events, audit trails, and replay, without adding a second platform. The result is comparable messaging characteristics with a broader capability set on the same footprint.

Manufacturing and logistics. The event mesh extends to where the events actually happen. Leaf nodes run in plants, on vehicles, in depots, and in warehouses, with store-and-forward across intermittent links. Cloud and edge share one namespace and one security model, which is what these architectures have wanted for years.

IoT and connected products. Native MQTT termination on the same brokers that carry the rest of your event fabric removes the gateway tier. Devices publish and subscribe on subjects that services in the cloud already understand.

AI and agentic systems. Agent-to-agent communication needs a fabric that spans cloud and edge, supports request-reply and streaming, and provides strong tenancy. Subject-based messaging is a natural fit for how agents discover capabilities and route work. Synadia’s agentic AI direction treats NATS as that connective layer.

The bottom line

Solace and NATS share more than most middleware comparisons acknowledge. Subject-based messaging. Event mesh semantics. Pub/sub, point-to-point, and request-reply. MQTT and WebSockets. Hybrid management. That shared language is why a Solace to NATS migration is a concrete engineering project rather than a re-architecture.

What you gain by moving is scope. Streaming on the same substrate as messaging. A KV store and object store in the same binary. A full-mesh cluster model with superclusters built in. Leaf nodes that actually run at the edge. An open source license and a broad ecosystem. A structurally lighter footprint to license, run, and staff.

If you are evaluating your options, the fastest way to get concrete is to walk through your current Solace topology with our team and see what a NATS equivalent looks like for your workloads.

Want help from the NATS experts? Meet with our architects to get help tailored to your use case and environment.