Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes
Try free Book a demo

Comparison · An MQTT broker

A broker moves your data. It does not give it meaning.

Many Unified Namespace projects start by choosing a broker, which is a reasonable first step: MQTT is the right transport for this problem. The trap is assuming that once the broker is running, the namespace exists. A broker carries whatever you publish, including an inconsistent model.

Book a demo All comparisons
What it is
An MQTT broker: Messaging infrastructure, for example HiveMQ, EMQX or Mosquitto
What Proxus is
An industrial data platform: collect, model, govern, store, deliver
Honest summary
The right transport for a Unified Namespace, and not a substitute for one.
Your options
Keep your broker as the transport and let Proxus publish readings into it, in plain MQTT or Sparkplug B, or subscribe to the namespace on the broker built into each Proxus gateway. Both paths are below.

Give them their due

What An MQTT broker is genuinely good at.

A comparison that only lists the other product's weaknesses is a sales sheet, not a decision aid. These are real strengths, and some of them are reasons not to buy Proxus.

  • The right transport, done properly

    Enterprise brokers offer QoS delivery, clustering and fine-grained security. That is real engineering and it is not the part you should build yourself.

  • Neutral by nature

    Anything can publish and anything can subscribe. No vendor owns the topic space, which is exactly why brokers became the backbone of UNS architectures.

  • Operationally well understood

    Your IT team probably already knows how to run one, monitor it and secure it. That familiarity has real value.

  • Excellent Sparkplug B support

    Where devices speak Sparkplug B, a broker plus Sparkplug gives structure and birth/death semantics without a platform in between.

  • Broker vendors sell more than the broker

    They pair the broker with edge connectivity (HiveMQ Edge, EMQX NeuronEX) and namespace governance (HiveMQ Pulse). Compare those combinations, not the broker alone.

Attribute by attribute

Where the two actually differ.

Both columns are filled in. Where An MQTT broker is ahead, the row says so.

  • What it does

    Proxus

    Reads equipment, models the values, governs access, stores history and delivers, with MQTT as one of the transports.

    An MQTT broker

    Transports messages reliably between publishers and subscribers.

  • Getting data from a PLC

    Proxus

    Native drivers for 66 protocols across 30 vendor and standard families read the controller directly.

    In the docs: Getting data from a PLC

    An MQTT broker

    Out of scope for the broker itself. Something has to read the controller and publish it; broker vendors sell separate edge products for that.

  • Who defines the topic structure

    Proxus

    A modelled namespace with templates, so the structure is a property of the platform rather than a document.

    In the docs: Who defines the topic structure

    An MQTT broker

    Every publisher, independently, unless a separate governance product is added. Without one, consistency is a convention you enforce with review.

  • Units, quality and context

    Proxus

    Attached at collection: unit, scaling, data type, quality flag and asset path.

    In the docs: Units, quality and context

    An MQTT broker

    Whatever the payload happens to carry.

  • History

    Proxus

    Built-in telemetry historian with retention policy.

    In the docs: History

    An MQTT broker

    Retained messages are not history. Storage is a separate system.

  • Access control

    Proxus

    Roles and permissions on namespace paths for people, REST API clients and AI clients. The broker built into the gateway has no per-topic rights, so keep broker ACLs where many clients subscribe.

    In the docs: Access control

    An MQTT broker

    Topic-level ACLs, which are powerful but only as coherent as the topic space beneath them.

  • Outage behaviour

    Proxus

    Edge buffering for the hub and for every outbound target, with delivery status per target, as product behaviour.

    In the docs: Outage behaviour

    An MQTT broker

    Client-side queueing depends on each publisher’s implementation.

  • Broker included

    Proxus

    Each gateway runs its own MQTT broker with the namespace topics, for applications to subscribe to and devices to publish to, and publishes readings to an external broker where one already exists.

    In the docs: Broker included

    An MQTT broker

    The product itself.

Proxus figures come from the current build's own driver and target inventory. An MQTT broker figures come from the vendor's published material, linked at the end of this page. Nothing here is measured on a benchmark neither party has agreed to.

Choose An MQTT broker

When we are not the answer.

  • You already have publishers that produce well-structured data and you need reliable transport between them.
  • The requirement is messaging infrastructure at a scale where clustering and HA are the hard part.
  • Your devices speak Sparkplug B natively and the structure that gives you is sufficient.
  • You have the engineering capacity to own the topic conventions and enforce them across teams.

Choose Proxus

When the shape of the problem fits.

  • Nothing is publishing yet, because the data is still inside PLCs that speak their own protocols.
  • You want the namespace to be enforced by the software rather than by a document nobody reads.
  • History, dashboards and delivery to databases are part of the requirement.
  • Ownership of the model matters: who decides what a topic means, and who can change it.

If this column describes you:

See a PLC publish into a modelled namespace on a demo

Not either/or

How they are used together.

  • Publish into your broker

    Where an enterprise broker is already the backbone, Proxus publishes readings into it: plain MQTT to one topic you choose, or Sparkplug B under your Group ID and Edge Node ID.

  • Give the broker something to carry

    The machines that cannot publish anything today are exactly what Proxus connects. The broker keeps its role; the topic space gains structure.

  • Two layers of access control

    Broker ACLs govern who reads which topic; namespace permissions govern what people, API clients and AI clients see in Proxus. They complement each other rather than compete.

Sources

Last checked against vendor material: October 2026.

Products change. If something on this page is out of date or wrong, tell us and we will fix it, including when the correction favours An MQTT broker.

Questions

Proxus and An MQTT broker: short answers.

Does Proxus replace our MQTT broker?
It does not have to. Proxus publishes readings into an existing broker: the MQTT target sends them to one topic you choose, the Sparkplug B target under your Group ID and Edge Node ID. The full namespace topic tree is on the MQTT broker built into each gateway, where your applications subscribe and devices can publish.
Can Proxus read PLCs that do not publish MQTT?
Yes. Native drivers for 66 protocols across 30 vendor and standard families read the controller directly.
Do retained messages count as history?
No. Retained messages are not history. Proxus includes a built-in telemetry historian with retention policy.

Proven in production

Running in production at these sites.

All deployments

Other comparisons

All comparisons

Next step

Give your broker something structured to carry.

Tell us which controllers still keep their data to themselves and which broker you run. In thirty minutes we show those signals on the gateway’s namespace topics, with units, quality and their place in the plant, and published into your broker.

Book a demo Talk to an engineer
  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.