Solace MQTT: What Works, the Documented Limits, and Plant Broker Design

Solace MQTT support covers the two current OASIS versions, MQTT 3.1.1 and MQTT 5.0, with the Solace Event Broker acting as the MQTT server over TCP, TLS, WebSocket and secure WebSocket (Solace, Using MQTT). For most plant telemetry that is all you need. The question that decides a design is the documented limits, and they are specific: QoS 2 is treated as QoS 1, shared subscriptions run only at QoS 0 on non-durable sessions, and retained messages are a Controlled Availability feature, as of October 2026.

This page states those limits precisely, explains what each one means on a production line, and covers when to keep a plant MQTT broker in front of Solace. It belongs under Solace protocols and APIs in the Solace cluster. For MQTT itself, start with our guide to MQTT in manufacturing.

What Solace MQTT supports

Feature	Solace behaviour	Source
Versions	MQTT 3.1.1 and MQTT 5.0, server role only	Using MQTT; conformance
Transports	TCP, TLS, WebSocket, secure WebSocket	Component maps
QoS 0	Supported	Using MQTT
QoS 1	Supported, using the broker’s guaranteed messaging	Using MQTT
QoS 2	Accepted, treated as QoS 1	Conformance
Shared subscriptions	QoS 0 only, non-durable sessions only	Using MQTT
Retained messages	Controlled Availability, through retain caches	Using MQTT
Will messages	Supported in both versions, “with certain limitations”	Conformance
Cross-protocol delivery	MQTT messages can reach JMS, AMQP, REST and SMF consumers	Protocols and APIs

The documented limits of Solace MQTT, precisely

Solace’s MQTT 5.0 conformance document and Using MQTT page state these in so many words:

1. QoS 2 publishes: “QoS 2 messages from clients are accepted but are treated as QoS 1 messages.”
2. QoS 2 subscriptions: “QoS 2 subscriptions from clients are accepted but are downgraded to QoS 1.”
3. Shared subscriptions: “Only QoS 0 shared subscriptions are supported”, “shared subscriptions are supported only on non-durable sessions”, and “QoS 1 shared subscriptions are downgraded to QoS 0.” Non-durable means CleanSession=1 in 3.1.1 or a session expiry of 0 in 5.0.
4. Retained messages: “Support for MQTT Retained Messages is a Controlled Availability (CA) feature.”
5. Guaranteed messaging off: without guaranteed messaging, “all QoS 1 and QoS 2 MQTT topic filters are downgraded to QoS 0.” This is a configuration trap rather than a product limit: QoS 1 needs message spooling enabled on the Message VPN.

What each means on a line. QoS 2 promises exactly-once delivery. Downgraded to QoS 1, a consumer can receive a duplicate after a reconnect, so a counter that adds every “case packed” event can overcount. The cure is an idempotent consumer: carry a sequence number or event ID and discard repeats. QoS 0 shared subscriptions mean a pool of load-balanced MQTT consumers can lose messages if one of them drops, which is acceptable for a live dashboard and not for a quality record. Retained messages in Controlled Availability mean a new subscriber may not get “last known state” the way it would on a broker where retain is a general feature.

None of this is unusual. AWS IoT Core also has no QoS 2, and most unified namespace designs run on QoS 0 and 1. But the limits must be known before a design depends on the opposite.

Edge devices, sessions and topics

Topics carry straight across. An MQTT topic such as site1/packaging/line3/filler/state is routed as a Solace topic, so the same hierarchy serves MQTT clients and Solace or JMS consumers. MQTT’s + and # wildcards play the roles of Solace’s * and >. The topics and wildcards page covers designing the tree.

Persistent sessions need guaranteed messaging. A durable MQTT session with QoS 1 subscriptions asks the broker to hold messages while the client is away. On Solace that uses the spool, so it counts against the Message VPN’s spool quota. A gateway that goes offline for a weekend can fill it. Size quotas per client profile, and alert on them.

Sparkplug B is a separate question. Sparkplug relies on retained state messages and correct will handling. A Solace community user reported a passing Eclipse Sparkplug test run against broker 10.5 in 2023, but Solace is not on the Eclipse compatible list. The Sparkplug B page covers it.

When to front Solace with a plant MQTT broker

Front Solace with a plant broker when Sparkplug state handling is central, when Ignition or other OT software is already built around an Eclipse-listed broker, when devices depend on retained messages, or when the controls team must run the site broker on its own. The bridge can be the plant broker’s own bridging feature or Solace’s Micro-Integration for MQTT.

Connect devices to Solace directly when traffic is QoS 0 or 1, retained state is not needed, and an IT or integration team will run the broker. That removes a component and lets every consumer use guaranteed queues from the first hop.

The trade-off is discussed further in Solace vs HiveMQ and, without a vendor lens, on the UNS broker page.

Testing Solace MQTT before go-live

A short acceptance test catches every limit above before it reaches production:

1. Inventory client settings. For each gateway, SCADA module and application, record the MQTT version, QoS per topic, session type, and whether it publishes or expects retained messages.
2. Enable guaranteed messaging on the Message VPN and confirm a QoS 1 subscription is granted at QoS 1, not QoS 0.
3. Publish at QoS 2 deliberately and confirm consumers handle the resulting QoS 1 duplicates.
4. Drop a durable client for an hour at production rate and measure spool growth against the quota.
5. Restart a subscriber and check what “last known value” it receives, with and without retain caches configured.
6. Fail over the broker under load and count lost and duplicated messages per consumer.

An illustrative case. A bottling plant connects twelve line gateways straight to a Solace broker at QoS 1. The OEE dashboard subscribes with a shared subscription so two dashboard servers split the load, and it works in the pilot. In production, one server restarts during a shift change and the counts for that half hour come up short. Nothing was misconfigured: QoS 1 shared subscriptions run at QoS 0 on Solace, as documented. Moving the dashboard servers to a non-exclusive Solace queue, read through a Solace API or JMS, gives the same load sharing with guaranteed delivery. That is the kind of finding the test above is designed to surface in week one rather than month three.

Where it gets hard

• Duplicates after failover. With QoS 1, expect them and design for them. Test by killing a client mid-publish.
• Spool exhaustion from durable sessions. One silent gateway with a persistent session can grow its backlog for days.
• Shared subscription expectations. Teams moving from a broker where QoS 1 shared subscriptions work may lose messages without noticing.
• Controlled Availability features. Confirm support status for retained messages in your release, in writing.
• Two topic trees. If the plant broker and Solace use different hierarchies, the bridge becomes a mapping engine nobody maintains. Agree one tree.

Related: Kafka integration for the analytics side, Kafka vs MQTT for the concepts, and the Solace hub.