Why MQTT is a good choice for machine data?

MQTT started as a lightweight messaging protocol for constrained devices and low-bandwidth connections, and it's become one of the more common ways to stream machine data to custom systems in real time. It works differently from the request-response patterns covered elsewhere on this blog, and understanding that difference is useful before deciding whether it fits a specific integration. This article covers how MQTT works and where it tends to make sense for machine data specifically.

Contents:

1. What MQTT is
2. How it works: brokers, topics, and publish/subscribe
3. Why MQTT fits machine data streaming
4. MQTT vs. other data delivery patterns
5. A typical architecture
6. Designing a topic structure
7. QoS levels and security
8. Frequently asked questions
9. Conclusion

What MQTT is

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish/subscribe messaging protocol originally designed for unreliable, low-bandwidth networks — a profile that fits industrial and IoT environments well beyond its original use case. It's a standard maintained by OASIS, implemented by numerous open-source and commercial brokers, and widely adopted across industrial IoT platforms specifically because of its low overhead compared to heavier protocols.

How it works: brokers, topics, and publish/subscribe

• Broker. A central server that all clients connect to. Publishers send messages to the broker; subscribers receive messages from the broker. Publishers and subscribers never communicate directly with each other.
• Topics. Messages are published to a named topic (e.g. factory/line1/machine3/spindle_load), and clients subscribe to specific topics or topic patterns to receive only the messages relevant to them.
• Publish/subscribe. A device publishing data doesn't need to know who, if anyone, is subscribed — it just sends to a topic. Any number of subscribers can receive the same message, and subscribers can be added or removed without the publisher needing to change anything.

This decoupling is the core structural difference from a REST API: a REST client explicitly asks a specific server for data on demand, while an MQTT publisher just announces data to a topic, and interested parties are set up independently to listen for it.

Why MQTT fits machine data streaming

• Low overhead. MQTT's message format is compact compared to typical HTTP-based APIs, which matters when publishing frequent updates from many machines simultaneously.
• Push, not poll. Machines (or the edge devices representing them) publish updates as they occur, rather than waiting to be asked, which avoids the wasted requests inherent in polling for data that hasn't changed.
• Many subscribers, one publisher. A single machine's data stream can be consumed simultaneously by a dashboard, a data warehouse loader, and an alerting system, all subscribing independently without adding load to the machine-side connection.
• Built-in handling for unreliable connections. Features like persistent sessions and "last will" messages (a broker automatically notifying subscribers if a client disconnects unexpectedly) suit the less-than-perfect connectivity common on real shop floors.

MQTT vs. other data delivery patterns

It's worth placing MQTT alongside the other data delivery approaches covered on this blog. Compared to REST APIs, MQTT is push-based and better suited to continuous streaming rather than on-demand historical queries. Compared to webhooks, which also push data, MQTT supports many simultaneous subscribers to the same stream without the publisher needing to manage a list of destination URLs, and it's designed for continuous telemetry rather than discrete, occasional events. None of these approaches is strictly superior; MQTT tends to be the right choice specifically when you need efficient, real-time streaming to potentially multiple consumers at once.

A typical architecture

In most manufacturing setups, machines don't publish to MQTT directly — an edge device or gateway reads the machine's native interface (MTConnect, OPC UA, FOCAS, or whatever fits the controller, as covered in our data acquisition architecture overview) and republishes selected values as MQTT messages. The broker itself typically runs either locally within the plant or in the cloud, depending on the broader edge vs. cloud architecture chosen. From there, any number of subscribers — a monitoring dashboard, a data warehouse loader, a custom application — connect to the broker and receive the topics they care about.

Designing a topic structure

Topic naming is entirely up to whoever designs the system — MQTT itself doesn't enforce a structure — but a consistent, hierarchical pattern makes subscribing and filtering much easier. A common approach mirrors physical or logical structure: site/line/machine/signal, for example plant1/line3/mill7/spindle_load. This allows a subscriber to listen broadly (all data from an entire line, using a wildcard) or narrowly (one specific signal from one specific machine) without the publishing side needing to change. Poorly planned topic structures — inconsistent naming, missing hierarchy — tend to become a maintenance headache as the number of machines and signals grows.

QoS levels and security

• QoS 0 (at most once) delivers a message with no acknowledgment or retry — fastest, but a message can be lost if delivery fails, generally acceptable for very frequent, non-critical telemetry where an occasional missed reading doesn't matter.
• QoS 1 (at least once) guarantees delivery but can result in duplicate messages, requiring the subscriber to handle potential duplicates gracefully.
• QoS 2 (exactly once) guarantees a message is delivered exactly one time, at the cost of more protocol overhead — typically reserved for cases where duplicate or missing messages would cause real problems, such as billing-relevant data or discrete event counts.
• Security should include TLS encryption for data in transit and authenticated connections (username/password or certificate-based) to the broker; an unsecured MQTT broker exposed on a network is a genuine risk, since anyone who can reach it can potentially publish or subscribe to any topic without restriction unless access control is explicitly configured.

Frequently asked questions

Do I need to run my own MQTT broker?

Not necessarily. Managed cloud MQTT broker services exist, and some monitoring platforms include broker functionality as part of their offering. Running a self-hosted broker gives more control but adds infrastructure to maintain.

Is MQTT suitable for historical data queries, or only real-time streaming?

MQTT itself is a streaming protocol, not a historical data store — it delivers messages as they're published, but doesn't retain history for later querying unless something on the subscriber side stores incoming messages. For historical queries, a REST API against stored data is generally more appropriate.

Can multiple systems subscribe to the same machine data stream without affecting each other?

Yes, this is one of MQTT's core strengths — any number of subscribers can independently receive the same published messages without the publisher needing to know how many consumers exist or manage delivery to each one separately.

What happens if a subscriber is offline when a message is published?

It depends on QoS level and session configuration. With persistent sessions and QoS 1 or 2, the broker can hold messages for a disconnected subscriber and deliver them once it reconnects; with QoS 0 or non-persistent sessions, messages published while a subscriber is offline are simply missed.

Conclusion

MQTT fills a specific gap in machine data delivery: efficient, real-time streaming to potentially many consumers, without the overhead of repeated polling or the one-to-one nature of webhooks. It's not a replacement for the machine-facing protocols that get data off a controller in the first place, but a common and effective way to move that data onward to whatever custom systems need to react to it as it happens.

Related articles:

• Webhooks for Real-Time Machine Events
• Feeding Machine Data into Custom Systems via API
• Edge vs Cloud Data Collection: Trade-offs
• Shop Floor Network Setup for Machine Monitoring
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.