OPC UA vs MQTT for Machine Data Aggregation

This comparison is most useful after the plant already knows how it will access the machine data. OPC UA and MQTT solve different parts of the problem. That is why many debates around them become noisy. Teams compare them as if they are interchangeable, then discover later that the real issue was translation at the machine boundary rather than transport upstream.

Quick answer

Choose OPC UA when the project needs structured industrial interoperability, plant-software friendliness, and a model that fits existing OT systems. Choose MQTT when the project benefits from lightweight publish-subscribe behavior, decoupled downstream consumers, and cloud- or analytics-oriented distribution. The wrong move is treating either protocol as the fix for messy machine-side access. If the field boundary is weak, the transport choice will not rescue the architecture.

The cost difference teams usually miss

Public pricing makes one thing clear: MQTT often introduces a visible platform cost, while OPC UA is frequently bundled into existing plant software, devices, or gateways.

Public component	Published price snapshot	Why it matters
HiveMQ Cloud Starter	starting from $0.34 per hour plus $0.80 per million messages	MQTT often introduces an explicit broker-service line item
EMQX Dedicated Flex	starts at $234 per month	A more serious managed MQTT footprint carries obvious recurring cost
Advantech UNO-220-P4N1AE on DigiKey	$137.70	A very small boundary device can already expose useful data without turning transport into the main cost driver
Moxa MGate MB3170 listing on DigiKey Marketplace	public listings around $586 to $615, with related models from $356 upward	Field translation often costs more than the protocol debate admits

This matters because buyers often compare protocols as if transport is free. It is not. MQTT frequently adds a broker or platform line item that the team should budget explicitly. OPC UA often looks cheaper only because parts of its cost are already hiding inside the existing OT stack.

Which layer this decision really belongs to

In many retrofit projects:

serial or field protocols determine how data is accessed from the asset;
gateways or converters normalize that access;
OPC UA or MQTT shape how data is exposed upstream to software, historians, MES layers, or cloud systems.

That means OPC UA versus MQTT is usually not the first decision. It is a later architecture choice that depends on the consumers, support model, and how many downstream systems should see the data.

When OPC UA is usually the cleaner answer

OPC UA is often the better fit when:

the destination systems are plant-centric and already understand OPC-oriented workflows;
the team values browseable industrial semantics and structured tags;
the architecture is more internal-to-plant than cloud-distribution oriented;
OT maintainability matters more than lightweight event distribution.

That is why many plants with historians, SCADA, MES, or vendor ecosystems already built around industrial software patterns remain very comfortable with OPC UA.

When MQTT earns the extra layer

MQTT becomes attractive when:

the project needs publish-subscribe behavior instead of tightly coupled polling;
multiple downstream consumers should receive selected machine data;
cloud, analytics, or event-driven systems are already part of the plan;
the team wants more decoupling between producers and consumers.

This is where the broker cost can be worth it. The question is whether your architecture really benefits from that distribution model.

The hidden trap in the comparison

The most common trap is calling MQTT modern and OPC UA old-fashioned, or calling OPC UA industrial and MQTT too cloud-oriented. Those labels are not useful. The better question is:

Which transport model best matches the software systems that will consume this data, and who will support that model after commissioning?

That answer is what should drive the choice.

A practical budget view

If the project is small, a public MQTT broker cost can quickly dominate the visible software line item while the hardware remains modest. For example:

HiveMQ Cloud Starter at $0.34 per hour is roughly $245 per month before message usage;
EMQX Dedicated Flex starts at $234 per month.

That may be acceptable if the architecture truly needs MQTT. It is much harder to justify if the plant only needs one or two upstream consumers and no meaningful decoupling.

On the other hand, if the plant is already carrying licensing or infrastructure around OPC UA-enabled software, the incremental cost of staying with OPC UA can be lower even if the total platform cost is not obvious.

The better decision sequence

Use this order:

confirm how the machine data will be extracted at the field boundary;
name the actual upstream consumers;
decide whether consumers need browseable industrial semantics or distributed publish behavior;
budget the explicit broker or platform cost if MQTT is chosen;
verify who will own monitoring and troubleshooting after go-live.

This keeps transport from becoming a standards argument detached from the real system.

Implementation checklist

The project is ready when:

the field-access problem is already understood;
the team has named the real upstream consumers;
public pricing for MQTT broker options has been considered where relevant;
hardware and protocol translation costs are not being confused with transport cost;
the support team knows which model it can actually maintain.

If several of those are still vague, the transport decision is premature.

Compare next

Modbus, OPC UA, and MQTT fit Step back to the larger protocol-role question before forcing a head-to-head comparison.

Edge data logging gateways for retrofits See how hardware choice changes what transport decisions matter upstream.

PLC data collection for mixed-vendor lines Watch the transport decision behave inside a real mixed-controller retrofit.

Retrofit gateway shortlist criteria Choose the device shortlist that matches the protocol role you actually need.