UNS Broker: How to Choose a Broker for a Unified Namespace

A UNS broker is the message broker at the centre of a unified namespace: the place where PLC gateways, SCADA, MES, historians and enterprise systems publish current state and subscribe to each other’s changes. Choosing one comes down to four questions. How many sites does the namespace span? Does it use Sparkplug, and do hosts depend on Sparkplug state? Which systems consume it, and over which protocols? And who will run the broker on night shift? For a single plant, a well-run MQTT broker, often the one the controls team already knows, is usually the right answer. For many plants, the answer is a broker per site plus an enterprise layer above it.

We cover the unified namespace pattern itself in our UNS guide and MQTT in our MQTT guide. This page assumes both and focuses on the broker decision, as part of our event-driven architecture guide.

What a unified namespace needs from its broker

A UNS puts specific demands on the broker that a generic message queue does not meet. Use this as the requirements list for any UNS broker shortlist.

Requirement	Why it matters in a UNS	What to ask
Retained messages	A new subscriber, such as a dashboard opened at shift change, must see current state at once, not wait for the next change	Is retain fully supported, at what scale, and is it persisted across restarts?
Last will and session state	SCADA must know when a gateway drops off, and edge nodes must resume cleanly after a reconnect	Are will messages and persistent sessions supported on every protocol version you use?
Hierarchical topics and wildcards	Consumers subscribe to site/area/line/# rather than to thousands of tags	Any limits on topic depth, length or wildcard subscriptions?
Access control per topic	A contractor’s app may read one line; a cloud service may read summaries only	Can permissions follow the ISA-95 hierarchy, and integrate with your directory?
High availability	The namespace becomes a dependency for SCADA screens and MES	Clustering or active-standby, failover time, and what clients see during failover
Sparkplug behaviour	Sparkplug hosts rely on retained STATE messages and correct will handling	Is the broker on the Eclipse list, and does it add Sparkplug-aware features?
Bridging and integration	Some events must leave the site for the enterprise or the cloud	Native bridges, Kafka or cloud connectors, buffering during WAN loss
Observability	When a dashboard freezes, someone must see which client or topic is the cause	Metrics, per-client statistics, integration with existing monitoring

MQTT 5 is worth requiring. Its reason codes, message expiry, shared subscriptions and user properties (OASIS) make troubleshooting and scaling easier, and most current brokers support it.

Plant UNS broker vs enterprise backbone

A unified namespace has a natural boundary. Inside a plant, the namespace is current state for local consumers, and the broker sits at ISA-95 levels 2 to 3, near SCADA and MES. Above the plant, corporate systems need a subset of those events with guaranteed delivery across the WAN, and often over other protocols such as JMS, AMQP or Kafka. Those two jobs have different owners, different failure modes and often different products.

• The plant broker is owned by controls engineering or the site OT team. It must keep the site running when the WAN is down, and it should be simple enough to support at three in the morning.
• The enterprise layer is owned by IT or an integration team. It carries the events other sites and enterprise systems need. It can be a federation of MQTT brokers, an event mesh, or a Kafka platform reached through bridges, as described in Kafka vs MQTT.

The mistake to avoid is building one central broker for all plants because it looks simpler. It makes every plant’s screens depend on the WAN, and it puts plant-floor tag traffic on a link that only needed a fraction of it. Solace’s own manufacturing writing makes a similar point from the enterprise side: keep UNS where it works, and do not force every use case into MQTT (Solace).

Sparkplug and the UNS broker

Sparkplug is an Eclipse Foundation specification that adds a topic namespace, a Protobuf payload and session state (birth and death certificates) on top of MQTT. Version 3.0 was published as ISO/IEC 20237:2023 (Eclipse). It matters for broker choice in three ways.

Sparkplug runs over any conformant MQTT broker, but it depends on retained messages and correct last will handling. A broker that downgrades or restricts those features can break host applications in subtle ways.

Sparkplug-aware brokers add more. The specification describes optional broker behaviour, such as storing birth certificates so that a new subscriber can learn the current state of every edge node. Brokers on the Eclipse compatible list have passed the Technology Compatibility Kit at a point in time. As of October 2026 the listed brokers are HiveMQ (Community and Professional), NanoMQ and Cirrus Link Chariot (Eclipse list).

Not being listed is not the same as failing. Some vendors have not submitted. Solace, for example, is not listed, although a Solace community post in 2023 reported a passing test run on one broker version with retained messages configured; the Solace Sparkplug page sets out what that does and does not mean. If Sparkplug hosts are central to your plant, prefer a listed broker or test the one you want.

The UNS debate about Sparkplug is real: its namespace is organised around edge nodes and devices, not around the ISA-95 hierarchy many UNS designs use. Many plants run both, with Sparkplug for device data and a plain JSON namespace for contextualised data. Decide that before choosing the broker, because it decides which broker features you depend on.

A decision tree for choosing a UNS broker

UNS broker options by category

Facts as of October 2026, from each vendor’s documentation and the Eclipse list. The event broker comparison covers the wider market.

Category	Examples	Typical fit
Broker inside the SCADA or DataOps platform	Ignition MQTT Distributor module, brokers built into HighByte Intelligence Hub and Litmus	One site, small team, already running that platform
Lightweight open source	Eclipse Mosquitto, NanoMQ	A line, a cell, a lab or an edge gateway; limited clustering
Sparkplug-focused	Cirrus Link Chariot	Ignition-centric plants that want native Sparkplug state handling
Clustered MQTT platforms	HiveMQ, EMQX	Site-wide or enterprise MQTT with high availability and many clients
Open-source UNS stacks	United Manufacturing Hub (MQTT front end, Kafka-compatible buffer inside)	Teams that want a free, opinionated stack and will support it themselves
Enterprise backbones that speak MQTT	Solace, SAP’s advanced event mesh (built on Solace), NATS	The layer above the plant brokers, across sites and protocols
Cloud MQTT services	Azure Event Grid MQTT broker, AWS IoT Core	Cloud-side namespace for an Azure- or AWS-centred estate; not inside the plant

The Ignition option deserves a word. Inductive Automation’s documentation states that the broker “can be an Ignition Gateway with the MQTT Distributor Module installed, or a third-party server” (Inductive Automation). Starting with the built-in broker is reasonable for one site. The question to ask early is what happens when the namespace serves more than SCADA: other consumers then depend on a gateway that was sized and patched for SCADA. Our article on connecting Allen-Bradley PLCs to Ignition covers the layer underneath.

Sizing and operating a UNS broker

Count clients and changes, not tags. A plant with 200,000 tags but report by exception may produce a modest message rate; a plant publishing every value every second produces far more. Before asking vendors for sizing, gather three numbers per site: connected clients, messages per second at peak, and the number of retained topics.

Plan for the consumers you will add. A UNS succeeds by attracting consumers: dashboards, MES, quality, maintenance, AI tools. Each adds connections, subscriptions and retained-message reads at reconnect. A broker sized for the pilot often struggles in year two.

Run it like infrastructure. Version the topic convention, monitor client counts and queue depths, patch on a schedule, and test failover before production depends on it. Our edge solutions article covers where the gateways that feed it should live.

Limits and open questions

• A broker is not a historian. It holds current state, one retained message per topic. History belongs in a historian that subscribes to the namespace; see where the historian sits next to the UNS.
• UNS is a pattern, not a standard. Vendors define it differently, and some critiques note that current state and events are often conflated. Write your own definition down.
• Sparkplug status changes. The Eclipse list is updated over time and reflects what vendors submitted. Sparkplug version 4 is in development.
• Cloud MQTT services deviate from the standard. AWS IoT Core does not support QoS 2, and Azure Event Grid’s MQTT features have arrived in stages (retain and shared subscriptions reached general availability in April 2026). Check before relying on a feature.
• Enterprise brokers may downgrade MQTT features. Read the MQTT conformance page of any enterprise backbone, as our Solace MQTT page does for one vendor.
• Licences change. EMQX moved to the Business Source License from v5.9; check terms for clustered production use.

How to evaluate a UNS broker

• One site or several, today and in three years?
• Do Sparkplug hosts depend on broker behaviour, and is the broker listed or tested?
• Are retained messages, last will and persistent sessions fully supported on MQTT 5?
• Can access control follow the namespace hierarchy and your directory?
• What happens to SCADA screens during a broker failover?
• How do events leave the site, and what buffers them during a WAN outage?
• Who on the plant team can operate it, and what support is available at night?
• What does it cost at the client count you expect in year two?

If the namespace crosses the OT and IT boundary, settle the zones and conduits first: an OT network assessment is where we would start.

Deeper

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

• Solace and the unified namespace: one enterprise vendor’s view of UNS
• Solace and Sparkplug B: what a self-reported test and the Eclipse list each mean
• Solace with Ignition and HighByte: plant platforms publishing to an enterprise layer
• Kafka vs MQTT: the layer above the UNS broker
• Plant data: our wider view of how plant data moves

Back to the event-driven architecture hub.