...

To determine which one to use we need to understand the difference between MQTT and MQTT Sparkplug.

MQTT

MQTT is a lightweight messaging protocol designed for efficient communication between devices. It was created to address the challenges of transmitting data reliably over low-bandwidth, high-latency, or unstable networks — conditions commonly found in industrial settings, remote monitoring systems, and embedded devices.

...

These characteristics have made MQTT a popular choice in IoT ecosystems, enabling everything from smart home automation to large-scale industrial control systems.

MQTT in Industrial IoT (IIoT) systems

MQTT has become a key messaging protocol for Industrial IoT (IIoT) thanks to its lightweight design and efficient data delivery. Yet despite its strengths, MQTT lacks a standardized way to define and structure data, often leaving developers to build custom logic for every device type. This approach works — but it doesn’t scale easily.

...

This is where MQTT Sparkplug comes in. Sparkplug builds on MQTT’s foundation, adding data standardization, state awareness, and improved scalability — all essential for complex IIoT environments.

MQTT Sparkplug

MQTT Sparkplug is an open-source specification designed to bring structure and standardization to MQTT data in industrial environments. Built on top of MQTT, Sparkplug introduces a standardized payload format, a defined topic structure, and a set of state management rules. This ensures that devices, sensors, and software systems all speak the same language to seamlessly integrate data and improve scalability.

...

By combining these features, Sparkplug transforms MQTT from a flexible data transport protocol into a robust, self-describing communication standard for IIoT. It eliminates the need for custom parsing logic, reduces integration headaches, and enables true plug-and-play scalability across industrial networks.

Key Differences

...

This is the MQTT Distributor module or Chariot® MQTT Server

How MQTT Sparkplug Works

By introducing standardized messaging rules, Sparkplug ensures that data is not only delivered efficiently but also consistently understood across devices and applications. At the core of this system are Sparkplug’s defined message types, topic structure, and state management mechanisms.

...

When devices disconnect, the broker automatically alerts Host Applications by publishing a death certificate — preventing stale or inaccurate data from being mistaken as live.

Which One to Use?

The MQTT Sparkplug Transmitter is designed for to be used at the Edge of complex IIoT environments where data consistency, system state awareness, and scalability are critical.It is generally used at the Edge of an OT infrastructure.

• The Sparkplug Transmitter creates a Sparkplug Client 
• After connection to the MQTT server, two way communication is available between the Sparkplug Host Application and the Sparkplug Client
• Uses BIRTH and DEATH messages together with Primary Host ID to maintain system state awareness awareness
• Data is always published as QoS0.
  • This is because Sparkplug features ensure data delivery rather than MQTT itself.
• The published messages can be consumed by any Sparkplug Host Application such as MQTT Engine.
  • The topic uses the identified SPARKPLUG IDs for Group, Edge Node and Device
  • The payload includes Metrics, Timestamps and Metadata encoded using Google’s Protocol Buffers (Protobuf)
• Understands Ignition UDTs and can be configured to publish UDT definitions in BIRTH messages
• Is capable of publishing thousands of tag change (or many more) events in a single message with the payload containing all the associated metrics and meta data 

The UNS Transmitter is ideal for lightweight IT deployments where minimal data points are required by Enterprise consuming clients.

...

• The UNS Transmitter creates an MQTT Client
• After connection to the MQTT server, data can only be published from the MQTT Client to the MQTT Server
• Uses LWT to maintain system state awareness
  • Publishes a properties message for each tag on a client connection
• Data can be published as QoS0, QoS1 or QoS2
• The published messages can be consumed by any MQTT ClientIs capable of publishing a single data message for each tag change event
  • The topic is the identified Ignition tag path starting at the Tag Path defined in the transmitter
  • The payload is a JSON formatted payload containing contains only the tag name, dataType, value, timestamp and qualityCode
  Is capable of publishing a single properties message for each tag on a client connection
  • The topic is the Ignition tag path starting at the Tag Path defined in the transmitter extended by .props
  • The payload is a JSON formatted payload containing Ignition non default or custom property values quality formatted as JSON
• Publishes the leaf tags of Ignition UDTs (a.k.a. Sparkplug Templates) and the structure of the UDT (i.e. UDT name itself and folders in the UDT) become topic tokens
• Is limited to publishing a single data message for each tag change event
• This 'topic per datapoint' strategy is very expensive from a resource perspective on both the MQTT clients as well as the MQTT Server