RelayQ vs. Traditional MQTT Brokers

Different question, different tool

Most MQTT broker comparisons ask which broker moves messages fastest. For industrial systems, that is rarely the question that matters. The question that matters is: what happens when something misbehaves?

RelayQ is not a broker with extra features. It is a deterministic edge runtime for industrial data systems that includes a fully conformant MQTT 3.1.1 and 5.0 broker as one capability, alongside protocol translation, validation, persistence, and local processing, inside a single execution boundary.

What traditional brokers do well

Traditional MQTT brokers are mature, widely deployed, and good at their job: routing messages between publishers and subscribers at scale. Large clusters, plugin ecosystems, managed cloud offerings, and years of production history are real strengths. If you need a neutral, general-purpose pub/sub transport, they work.

Where the traditional model stops

In OT environments, three properties of the traditional model become the problem:

Neutral transport. Brokers forward what they receive. Malformed Sparkplug payloads, stale sessions, and out-of-sequence lifecycle messages pass through and become your SCADA layer’s problem.
Shared state. Shared queues and global locks mean a slow or misbehaving client can create back-pressure that other clients feel.
Stack sprawl. The broker is one box in a chain: protocol gateway, integration layer, cloud connector, each with its own dependencies, update cycle, and failure modes.

Side by side

	Traditional MQTT broker stack	RelayQ
Role	Message transport; protocol gateways and integration run as separate components	Single runtime: ingestion, validation, processing, and delivery in one execution boundary
Runtime dependencies	Roughly 15 packages for C-based brokers (including OpenSSL) to 200+ for Erlang-based stacks	0 mandatory dependencies: std-only core, TLS optional via rustls
Deployment	Broker + gateway + integration layer + connectors	One ~4.6 MB binary, field to cloud
Failure model	Shared queues; one client’s back-pressure can propagate	Per-client isolation; failure never crosses client boundaries
Malformed traffic	Forwarded as received	Validated at ingress; malformed Sparkplug B topics and out-of-sequence birth/death messages are rejected
Recovery	Varies by broker and configuration	WAL replay with atomic recovery; 0 message loss in soak and power-cut tests
Conformance evidence	Varies	134 MQTT 3.1.1 statement IDs and 269 of 277 MQTT 5.0 statements verified across 4,902 tests
Robustness evidence	Varies	6M malformed inputs fuzzed with zero crashes
Clustering	Multi-node clusters	Intentionally bounded: 2-node active/standby, no cluster-wide failure domain

Sources: the Sparkplug B conformance report, the benchmarks and method, and the dependency counts discussed in our supply-chain analysis. Any figure on this page is a lab measurement on the stated build; results in your environment will differ.

Where it runs

RelayQ is one runtime with three placements, chosen by what the zone already has. In the cabinet, on resource-constrained hardware, it runs on Linux for ARM. In the site’s OT zone, beside SCADA, DCS, OPC Classic servers and historians, it runs on the Windows machine or VM that zone already has, which is also the only place OPC Classic can be reached. In the data centre it runs on whichever server platform is the norm there. The Windows build is x86_64 and is not offered for resource-constrained hardware. Which build differs in what is listed once, in the Getting Started Windows section.

When a traditional broker is the right choice

Honesty cuts both ways. Choose a traditional broker when you need:

Broker clusters larger than two nodes, or web-scale fan-out beyond a single site
A managed cloud pub/sub service rather than on-premise infrastructure
Multi-tenant isolation inside one broker deployment
A specific plugin or extension ecosystem your platform already depends on

RelayQ’s intentional boundaries exclude these by design; it optimises for predictable behavior in bounded industrial systems, not for unbounded scale.

The short version

Traditional brokers route messages and stay neutral about their contents and their senders. RelayQ enforces validation, isolation, and bounded behavior at ingress, where an industrial system needs it. If your evaluation criteria include “what happens during failure”, test both under failure conditions and compare what breaks.