EMQX vs HiveMQ: Edge, Sparkplug, Clusters and Data Out Compared

A controls engineer planning a UNS for three plants soon has to pick the broker in the middle, and EMQX and HiveMQ both make the list. The differences sit in the edge products, Sparkplug handling, many-site design and the hand-off to other systems. Fabrico makes OEE software with a light MES, an application that would sit on top of such a broker, and sells neither product. Vendor facts come from emqx.com, docs.emqx.com, hivemq.com and docs.hivemq.com checked on 13.11.2026, with a link at each fact.

EMQX vs HiveMQ at a glance

Sources for the cells are linked in place, read on 13.11.2026.

What EMQX offers, per EMQ

The EMQX homepage talks of streaming real-time device data to cloud, AI and analytics. As of 13.11.2026:

• The broker. The EMQX documentation describes a large-scale distributed MQTT messaging platform. The EMQX product page lists MQTT 5.0, MQTT 3.1.1, WebSocket and QUIC, and deployment in your own data center or your AWS, Azure or Google Cloud environment.
• Plant floor. EMQX Neuron is presented as a modern industrial connectivity server with 70+ protocols and drivers, Modbus, OPC UA and Siemens S7 among them, publishing through MQTT and Sparkplug B on x86 or ARM hardware. EMQX Edge is a lightweight MQTT data backbone for the industrial edge, per its page, for Linux, Windows and Docker.
• UNS. EMQ's unified namespace solution page says a UNS organizes industrial data around a shared naming structure and agreed data models, with EMQX as the messaging hub for clustering, access controls, rules and data integration.

What HiveMQ offers, per HiveMQ

From HiveMQ's own pages, as of 13.11.2026:

• HiveMQ Broker. The HiveMQ Broker page lists MQTT 3.1.1 and 5.0 with full support, and says broker nodes can be added or removed without downtime. For hosting it names HiveMQ Cloud, described as fully managed, and self-managed deployment on private, hybrid and public cloud.
• Feature list. The HiveMQ user guide lists retained messages and clean and persistent sessions among supported MQTT features, and calls the broker 100% Sparkplug compatible.
• HiveMQ Edge. The HiveMQ Edge page presents a gateway whose pre-built protocol adapters turn device protocols into MQTT messages, with an offline buffer that keeps messages on disk until the link is back and a two-way bridge to enterprise brokers.

EMQX vs HiveMQ, job by job

Per MQTT.org, MQTT is an OASIS standard for IoT messaging, so the comparison is about what each vendor builds around the broker.

The broker at the centre of a UNS

Topic design stays with the plant team either way: the broker holds whatever tree the sites agree on, for example site, area, line and machine (see our guide to the ISA-95 levels and the unified namespace guide). Retained messages matter because a new subscriber should see the current state of a line at once. The MQTT 5.0 specification says that when a client publishes with the RETAIN flag set to 1, the server must replace any existing retained message for that topic and store the new one for future subscribers. EMQX's retained message docs say EMQX implements that feature, and HiveMQ's user guide lists it.

Edge options next to the machines

EMQ splits the edge in two: EMQX Neuron reads the controllers, and EMQX Edge runs a local broker whose bridge caching, per its page, stores configured upstream messages and retransmits them when connectivity returns. HiveMQ puts protocol conversion, the offline buffer and the bridge into HiveMQ Edge. See our guide to edge or cloud processing for shop floor data.

Sparkplug support

Sparkplug adds state awareness on top of MQTT; the Eclipse Sparkplug project says birth and death certificates give subscribing clients confidence in data validity. HiveMQ's Sparkplug page calls HiveMQ a fully Sparkplug compatible broker as defined by the latest Sparkplug 3.0 specification. The EMQX Sparkplug B docs describe built-in spb_encode and spb_decode functions and a Schema Registry, so rules can read and write Sparkplug B payloads, while EMQX Neuron publishes Sparkplug B from the edge.

Clustering for many sites

The EMQX clustering docs describe nodes working together as one system: core nodes handle writes and full data replication, replicant nodes handle client sessions, and the system keeps operating if one or more nodes go offline. HiveMQ's cluster guide describes a distributed masterless cluster with no single point of failure. With many plants, the links into the cluster need as much care: the EMQX product page speaks of connecting deployments across sites, regions and clouds through one MQTT infrastructure, and HiveMQ offers a broker bridge extension plus the bridge in HiveMQ Edge.

Data integration to other systems

Per the EMQX data integration docs, Sink and Source components connect EMQX with external systems: sinks send messages to targets such as Kafka, PostgreSQL, InfluxDB, TimescaleDB, MongoDB and Snowflake, while sources bring messages in from systems such as MQTT, Kafka or GCP PubSub, and SQL rules filter and transform messages on the way. HiveMQ's extensions catalogue covers moving data both ways with Kafka and Amazon Kinesis, writing it into PostgreSQL, MongoDB or Snowflake, and bridging brokers; its broker page adds a custom SDK for tailored extensions.

Match the first job

Start from the task the project must finish first.

If HighByte is on the list too, our HighByte vs HiveMQ comparison looks at a modelling hub next to a broker, and OPC UA vs MQTT covers the protocol choice underneath.

Decision matrix: EMQX or HiveMQ for your plant

Read down the first column. Each row points to the vendor pages that document the job; where both do, the pilot decides, not the brochure.

Broker failure modes to test before OEE depends on them

A broker pilot that only shows messages flowing proves little. Break these on purpose on a test line and note what the OEE screen did.

Two lines of the MQTT 5.0 specification decide most of this table (accessed 14.11.2026). On session expiry: "If it is set to 0, or is absent, the Session ends when the Network Connection is closed." So an OEE subscriber that restarts with that setting starts a fresh session and gets nothing queued for the gap. On the Will Message: it "MUST be published after the Network Connection is subsequently closed", once the Will Delay Interval has passed or the session has ended. A gateway that sets a Will on its state topic tells every subscriber its line is now unknown, instead of leaving RUNNING in place.

Security belongs in the same pilot. NIST's SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security (September 2023) covers typical OT topologies, threats and countermeasures, and ISA describes its ISA/IEC 62443 standards as setting out requirements and processes for implementing and maintaining secure automation and control systems (both accessed 14.11.2026). Decide which zone the central cluster and each edge broker sit in before the first gateway publishes.

Where OEE inputs meet the topic tree

A topic such as site2/meals/line3/traysealer/state can say RUNNING or STOPPED, and a count topic can tick up with output. OEE also needs planned production time from the shift pattern, a target rate for the product, the reject count, and the reason the line stopped, which a person at the line usually supplies.

QoS per topic matters here. The MQTT 5.0 specification says a QoS 0 message arrives at the receiver either once or not at all, with no response and no retry. On a state topic that drives availability, that has a cost.

Worked example: a lost QoS 0 stop message on a tray sealer

Every figure below is invented for a made-up ready-meals line: sample data, not tied to any customer or taken from a product screen. A tray sealer runs a 480 minute shift with 30 planned minutes for a break plus a hygiene clean, so planned production time is 450 minutes. At a rated 40 trays a minute the line could make at most 450 x 40 = 18,000 trays. An edge gateway publishes the sealer's state as a retained message, plus a running count.

At 13:40 the tray sealer stops for 18 minutes, waiting for lidding film. The state topic is set to QoS 0, and the STOPPED message is lost while the gateway's link drops and reconnects. When the tray sealer starts again, the reconnected gateway publishes RUNNING, which the OEE application already believes. A retained message holds the latest value, not the history, so the gap stays hidden.

The arithmetic. The count topic shows 14,850 trays and the reject signal 220, so 14,630 are good. As logged: 92.0% x 89.7% x 98.5% = 81.3%. Reconciled: 88.0% x 93.8% x 98.5% = 81.3%. Both equal 14,630 good of 18,000 possible (how OEE is calculated).

OEE holds because good output and planned time did not change; the visible loss does. As logged, the shift looks like a speed problem. Reconciled, it shows 18 more stopped minutes, waiting for lidding film, a cause that belongs to purchasing and the stores. The other 36 minutes were changeover 14, seal-head fault 13 and waiting for product 9.

The clue: the count topic stays flat for 18 minutes while the state says RUNNING, so a rule in the OEE layer or a supervisor can spot the gap and the operator adds the cause. State at QoS 1 or 2 plus edge buffering lowers the risk.

Carried to money. Take a sample contribution margin of EUR 0.30 a tray, made up for this page; ask finance for yours. The shift made 14,630 good trays of 18,000 possible, so 3,370 trays, or EUR 1,011, were lost. Reconciled, that splits into stops 54 x 40 = 2,160 trays (EUR 648), slow running 15,840 minus 14,850 = 990 trays (EUR 297) and 220 rejects (EUR 66). As logged, stops showed only 1,440 trays (EUR 432) and speed 1,710 trays (EUR 513). The EUR 1,011 total is right in both views; EUR 216 of it, the 720 trays the film wait cost, sits under the wrong owner.

On a three-shift plant with 20 production days, 60 shifts a month, a loss of this size is EUR 60,660 a month and EUR 727,920 over 720 shifts a year. If the lost stop message recurs on one shift in ten, 6 a month, the misfiled part is EUR 1,296 a month and EUR 15,552 a year: money spent chasing line speed while the film supply goes unfixed.

Where Fabrico fits for a UNS buyer

Fabrico is none of the products above: no broker, no edge gateway, no SCADA, HMI or DataOps tool. Beside a UNS it plays the OEE and light MES part, joining the machine signal with the shift plan, target rates and the reasons operators give.

• Signals. Machine stops and counts arrive as PLC tags, sensor pulses or counter values. MQTT is named among supported protocols, beside OPC UA and Modbus, on our machine connectivity page; the route for a machine is settled when the project starts.
• Stop reasons. At the line, an operator picks the stop reason from a phone or tablet. Fabrico then reports OEE and downtime for every line and shift, puts a money figure on the lost time, and runs on the web, iOS and Android (see the solution overview).
• Manual stations. Where a station is manual or a machine has no signal to read, the camera add-on counts output only. Stop reasons proposed by the camera are on the Roadmap. Its video is streamed on request and never stored. The camera add-on page has the details, and computer vision for FMCG manufacturing shows where it fits on packing lines.
• Data. A data team can pull results through the REST API, take webhooks, or export Excel or CSV files, and put stop reasons beside the broker data.

To watch shift plans and operator reasons join a broker-based stack, book a demo.

What to ask EMQ and HiveMQ

• Which of our controller models does your edge software read, and through which driver or adapter?
• Which QoS and retain settings do you recommend for state and count topics, and why?
• When a plant loses its link to the central cluster, where are messages buffered, and how much can be held?
• Which Sparkplug version have you tested, and with which host application?
• How are many plant brokers bridged to one cluster, and how are topic permissions kept consistent?
• How do you push one configuration change to many plants, and undo it?

The OEE software guide covers what sits above the broker.

What to do this week

Five steps for a controls, CI or operations manager with both vendors on the list:

1. Write down the QoS, retain and session settings each existing gateway uses for state and count topics. Anything at QoS 0 on a state topic goes on the risk list.
2. Check one shift for silent gaps. Look for spells where the count topic stays flat while state reads RUNNING, and ask the line what happened.
3. Pick the matrix rows that apply and send the same list, with the questions above, to EMQ and HiveMQ.
4. Plan the break tests. WAN cable out for 30 minutes, one broker node stopped, the OEE subscriber restarted. Agree what pass means before the pilot.
5. Price the gap. Get a per-tray margin from finance and repeat the money step above with last month's stop log.

What people ask next

How do EMQX and HiveMQ differ?

Both are MQTT platforms built around a clustered broker. EMQX surrounds it with EMQX Neuron for industrial connectivity, EMQX Edge as an edge broker and a SQL rule engine. HiveMQ surrounds it with HiveMQ Edge as a gateway and extensions for Kafka, databases and cloud services.

Do EMQX and HiveMQ support Sparkplug B?

Both say so on their own pages. HiveMQ calls its broker fully Sparkplug compatible as defined by the Sparkplug 3.0 specification. EMQX documents built-in functions that encode and decode Sparkplug B payloads in rules, and EMQX Neuron can publish data as Sparkplug B. Ask each vendor which host application they have tested with.

Can a lost MQTT message change OEE?

It can change how the figure splits. In the sample shift on this page, a lost QoS 0 stop message makes 18 stopped minutes look like slow running: availability reads 92.0% instead of 88.0% and performance 89.7% instead of 93.8%, while OEE stays at 81.3%.

Does EMQX or HiveMQ calculate OEE?

Both carry the state and count messages that OEE is built from. The shift plan, target rates and operator stop reasons usually sit in an OEE, light MES or MES application that subscribes to the broker, so agree early which system owns them.

Does Fabrico replace EMQX or HiveMQ?

No. Fabrico is the OEE and light MES application a broker would feed, not a broker or a gateway. It takes machine stops and counts from PLC tags, sensors or counters, keeps the reason the operator picks, and passes data on by REST API, webhooks or file export to Excel or CSV.

Want a stop cause from the line to sit next to your broker data? Book a demo.