The debate is framed as a war; it is actually two tools answering two questions. Confusing them produces architectures that leak meaning or drown brokers.
What each actually is
OPC UA is an information model with transport attached: typed nodes, structure, units, historical access, methods, discovery — a client can ask what the data means. Heavyweight accordingly; server-centric; the natural language of machine-to-MES integration, where contracts matter and consumers are few and serious.
MQTT is a transport with no opinions: topics and byte payloads through a broker, publish/subscribe, tiny footprint, firewall-friendly outbound connections, quality-of-service tiers. Fan-out to many consumers, cloud ingestion, intermittent links — its home turf. Meaning is whatever your payload convention says (JSON ad hoc, or Sparkplug B if you want state management and birth/death semantics — which you do, once devices number in the dozens).
The hybrid that keeps winning
Machines speak OPC UA locally (typed, secure, contract-style interfaces per our integration practice); an edge gateway subscribes/reads and publishes curated payloads via MQTT to the historian/cloud tier. Semantics preserved where they exist, transport economics where volume lives. The anti-patterns: raw PLC tags dumped to a broker (meaning lost at the source, forever), or OPC UA forced across flaky WAN links doing a job pub/sub does natively.
FAQ
Security models? Both do TLS properly when configured; OPC UA adds application-level certificates per client. The broker becomes critical infrastructure in MQTT designs — treat it like one (redundancy, access control, monitoring).
Sparkplug or plain JSON? Plain JSON scales badly past a pilot: no state, no schema, N naming conventions. Sparkplug’s discipline pays as soon as anyone besides the author consumes the data.
Zone Otomasyon builds edge-to-cloud pipelines that survive audits and vacations. Data architecture.