MQTT vs. REST vs. OPC UA: Which fits modern industrial architecture?

Industrial communication protocols have evolved dramatically over the last four decades. From the early days of serial polling to TCP/IP and now publish/subscribe architectures, the goal has remained the same: move data efficiently, securely, and reliably.

But as manufacturers connect more devices, expand to multi-site operations, and push analytics to the cloud, legacy communication models start to crack under the weight of modern expectations.

So which protocol actually fits the architectures of today and tomorrow? Let’s look at three of the most common approaches, REST, OPC UA, and MQTT, and how they differ in practice.

REST: Built for the web, not the plant floor

REST (Representational State Transfer) revolutionized web development. It’s simple, flexible, and perfect for occasional data requests or transactions. In a traditional IT setting, REST APIs let one system “ask” another for specific data when needed.

But in industrial environments, where thousands of sensors and controllers generate continuous streams of data, REST shows its limits.

  • It’s request/response based, not event-driven.
  • It lacks persistent connections.
  • It struggles to scale for real-time telemetry.

In other words, REST is great for configuration or reporting tasks but not for the constant data flow that modern OT systems demand.

“REST was designed for web traffic, not for the volume and persistence of industrial data,” explains Arlen Nipper, Cirrus Link CTO and co-creator of MQTT. “You can’t run a refinery or factory on HTTP requests.”

OPC UA: A legacy workhorse with local limits

OPC UA (Unified Architecture) evolved from OPC DA, the industry’s go-to standard for connecting software to hardware on the plant floor. It’s robust, structured, and well understood, a backbone for SCADA systems for nearly two decades.

And it still excels within a plant network.

But beyond that? The challenges start to show.

  • OPC UA is bandwidth-heavy and not optimized for wide-area networks.
  • It’s difficult to scale across distributed architectures.
  • Its security model doesn’t translate easily to cloud systems.

As Arlen puts it: “OPC UA is strong for local connectivity, but it was never built for the cloud. MQTT was.”

There have been attempts to tunnel OPC UA over MQTT to modernize it, but these efforts often add complexity without solving the fundamental design mismatch. The result: slow, brittle architectures that struggle to adapt.

MQTT: Lightweight, scalable, and cloud-native

Originally designed in the late 1990s to move oil pipeline data over expensive satellite links, MQTT was built for efficiency and reliability under constraints.

It uses a publish/subscribe model, meaning devices (publishers) send data only when it changes, and applications (subscribers) receive just what they need. A central broker handles distribution—decoupling systems so they no longer rely on direct, one-to-one connections.

The result?

  • Minimal bandwidth usage.
  • Real-time performance.
  • Built-in scalability and bidirectionality.
  • Seamless integration with cloud platforms like Snowflake, AWS, and Azure.

“MQTT wasn’t adapted for the cloud, it was designed for it,” says Nipper. “It’s event-driven, state-aware, and built around infrastructure, not hard-coded connections.”

Sparkplug: Turning MQTT data into context-rich information

MQTT provides the pipe; Sparkplug provides the structure.

The Sparkplug specification adds the context that industrial data needs, model definitions, state awareness, and standardized naming, so systems across an enterprise can automatically interpret and use the same information.

Without Sparkplug, you’re just moving numbers. With Sparkplug, you’re moving meaning.

This combination of MQTT and Sparkplug enables:

  • Plug-and-play data flow from edge to cloud
  • Self-discovery of devices and tags
  • True interoperability across vendors and systems
  • Real-time Unified Namespace architectures that scale

Side-by-side comparison

Feature

REST

OPC UA

MQTT (+ Sparkplug)

Communication model

Request/response

Client/server

Publish/subscribe

Connection type

Stateless

Stateful

Persistent

Cloud suitability

Moderate

Poor

Excellent

Bandwidth efficiency

Low

Medium

High

Real-time capability

Limited

Excellent

Excellent

Scalability

Web-level

Limited

Enterprise-level

Context awareness

None

Some

High (with Sparkplug)

Security

HTTPS-based

Built-in

TLS + authentication

Ideal use case

APIs, dashboards

Local SCADA

Edge-to-cloud integration

The takeaway: Right tool, right layer

Each of these technologies serves a purpose—but they live at different layers of the modern architecture.

  • REST belongs in the IT layer, for APIs and configuration.
  • OPC UA belongs in the OT layer, for device-level control and data access.
  • MQTT with Sparkplug bridges both—delivering real-time, contextual data from operations to enterprise systems.

Manufacturers that try to stretch OPC UA into the cloud or rely solely on REST for industrial data will hit the same wall: architecture that doesn’t scale.

MQTT with Sparkplug, on the other hand, was built to connect these worlds from the start—creating the foundation for scalable, event-driven, and future-ready operations.