If an industrial IoT system only needs to move a small set of readings into a cloud service, custom MQTT topics are often faster, lighter, and easier to fit into the existing backend. But once the same deployment grows into many gateways, many production lines, and many consuming applications, the hard problem usually stops being MQTT connectivity. It becomes semantic consistency, device state, and whether the platform can understand metrics without a custom adapter for every site.
Sparkplug B does not answer the question "can MQTT transport the data?" It answers a different question: "after industrial data reaches the platform, does it still carry enough context and lifecycle state to be trusted?" The Eclipse Sparkplug specification sits on top of MQTT and defines topic namespace, payload structure, Birth / Death state, and metric conventions. MQTT moves the bytes; Sparkplug B makes those bytes more self-describing for industrial systems.
The practical recommendation is simple. If SCADA / HMI systems, edge gateways, platform services, and operations tools need to work from the same industrial metrics, evaluate Sparkplug B first. If the goal is lightweight telemetry, application events, existing cloud integration, or a small number of consumers, custom MQTT topics can still be the better choice.
1. Start With the Decision
| Dimension | Sparkplug B fits better when... | Custom MQTT topics fit better when... |
|---|---|---|
| Data object | You model devices, gateways, metrics, and state | You send business events or simple telemetry |
| Platform goal | You need discovery, tag consistency, and lifecycle awareness | You need fast integration and naming flexibility |
| Lifecycle state | Birth / Death and rebirth behavior matter | Latest events or ordinary telemetry are enough |
| Payload | Protobuf and metric models are acceptable | JSON, CSV, or a custom binary format is easier |
| Team boundary | OT, platform, HMI, and analytics teams share data | One team owns both publisher and consumer |
| Cost | You can pay the upfront standardization cost | You can manage long-term naming and schema governance |
The decision after the table is not that Sparkplug B is always more advanced. Sparkplug B is valuable because it imposes a shared contract. If the receiving platform will not model edge nodes, devices, metrics, and lifecycle state, the standard may add complexity without enough payoff. On the other side, if the platform is already building tag governance, asset models, and operations dashboards, unrestricted custom topics tend to become a future integration cost.
2. What Sparkplug B Actually Adds
Sparkplug B is an industrial data specification layered on MQTT. It is not a new broker and it does not replace MQTT. The Eclipse Sparkplug project describes Sparkplug as a framework for MQTT clients to integrate data from applications, sensors, devices, and gateways within MQTT infrastructure. Sparkplug 3.0 formalized the specification under the Eclipse Foundation process and clarified earlier ambiguities.
For industrial projects, three additions matter most.
The first addition is a fixed namespace. With plain MQTT, one team might publish factory/line1/motor/temperature while another publishes site/a/eq/001/t. Both can work if every consumer knows the convention. Sparkplug B fixes concepts such as group, edge node, device, and message type, which helps a platform understand where a message came from and whether it represents Birth, Data, or Death.
The second addition is lifecycle semantics. MQTT has connection state and Last Will behavior, but plain MQTT does not make every receiving application understand whether remote data is current and valid. Sparkplug B uses Birth and Death messages so a platform can distinguish newly declared metrics, stale data from an offline node, and metrics re-announced after reconnect. For HMI, SCADA, and operations dashboards, that state often matters more than the numeric value alone.
The third addition is a metric payload model. Sparkplug B uses a defined payload structure to represent metric names, values, types, timestamps, and properties. The benefit is that downstream systems do not need to infer field meaning from every project-specific JSON payload. The cost is that edge software, platform services, and debugging tools must understand Sparkplug payloads instead of just opening a JSON message.
3. Why Custom Topics Still Matter
The main strength of custom topics is not just simplicity. It is control over the system boundary. When one edge service, one broker, and one consumer own the contract, custom topics and JSON payloads can move a project faster.
For example, a small building automation deployment may only need to publish temperature, humidity, and alarm state into a cloud API. In that case, the topic tree can follow the business object directly, the payload can be readable JSON, and logs are easy to inspect. Introducing Sparkplug B may shift the task from "send useful telemetry" to "support namespace, metrics, Birth / Death, and Sparkplug tooling" before the system needs those features.
Custom topics also fit business events. Warehouse recognition results, service-ticket updates, AI alert summaries, and rule-engine outputs are not always industrial tags. They do not necessarily need edge node lifecycle semantics. Forcing them into a metric model can make the data less clear, not more reliable.
The risk is governance. A custom design should define topic naming, payload versioning, units, timestamps, quality fields, and offline behavior before the second gateway or second consumer arrives. If those rules live only in memory, the project can look fast at first and become expensive once another site or application joins.
4. Decide From the System Goal
flowchart TD
A("Industrial MQTT project goal"):::slate --> B("Need automatic device and metric discovery"):::blue
A --> C("Only need lightweight telemetry or app events"):::green
A --> D("Multiple OT / IT applications consume the same data"):::orange
A --> E("Existing cloud platform already owns JSON contracts"):::violet
B --> F("Evaluate Sparkplug B first"):::blue
D --> F
C --> G("Use custom MQTT topics first"):::green
E --> H("Keep custom topics, define migration boundary"):::violet
F --> I("Govern namespace, Birth / Death, and metric model"):::orange
G --> J("Govern naming, payload version, and state semantics"):::slate
H --> J
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;The point of the diagram is to start with the system goal, not with a preference for a standard. If the goal is industrial semantic consistency, Sparkplug B's constraints are useful. If the goal is to move a message into an application quickly, custom MQTT topic flexibility is useful. The costs are opposite: Sparkplug B adds more structure up front and lowers collaboration cost later; custom topics move faster up front and require stronger governance later.
5. When Sparkplug B Should Be the Default Candidate
Sparkplug B deserves serious evaluation when at least two of the following conditions are true.
First, the device and metric set will keep expanding. When many production lines, gateways, device types, and sites feed the same platform, flexible topic naming turns into a data governance problem. Sparkplug B reduces the chance that the platform needs a one-off adapter for every field deployment.
Second, the platform must know whether a value is still valid. A temperature reading shown as 23 degrees does not prove that the device is online, or that the reading is still trustworthy. Birth / Death behavior helps the platform separate a fresh metric from stale data and from a node that has reconnected and re-declared its metric set. You can design this with custom topics, but each project must invent and test the convention.
Third, HMI, SCADA, historian, alarm, and operations applications all consume the same data. Once multiple systems coordinate around the same tags, semantic consistency becomes more important than publisher convenience. Sparkplug B often becomes valuable with the second or third consumer, not during the first demo.
6. When Sparkplug B Is the Wrong First Move
If the project only sends a small number of sensor readings to one cloud API, custom topics are usually more practical. The engineering focus should be readable topic names, payload versioning, monitoring, and clear offline semantics. Sparkplug B may be more structure than the system needs.
If the platform is built around business objects rather than industrial tags, avoid forcing everything into Sparkplug B. AI inspection results, user actions, work-order events, and order status changes are closer to event streams than industrial metrics. Encoding them as Sparkplug metrics can obscure their business meaning.
If the existing system already has mature JSON schemas, authorization rules, and backend processing, a full migration is also risky. A safer path is to use Sparkplug B for new industrial gateway or SCADA integration boundaries while keeping the existing custom topics. Expand the standard only when the platform truly needs discovery, lifecycle state, and tag consistency.
7. A Practical Hybrid Architecture
Many real systems should not choose only one pattern. They should separate layers.
From the edge gateway to the industrial platform, Sparkplug B can carry devices, edge nodes, metrics, Birth / Death, and operational state. That lets the platform build tags, alarms, history, and dashboards on top of stable semantics.
From the platform to business applications, custom topics or APIs may still be better. Business systems often care that a work order was created, an energy threshold was exceeded, or an AI inspection needs review. These events do not need to expose the Sparkplug namespace to every downstream service.
The boundary has to be explicit. Sparkplug B should own raw industrial state and metric context. Custom topics should own business events and application integration. Do not publish the same temperature point through Sparkplug B and another custom topic unless units, timestamps, quality, and lifecycle rules are aligned. Two correct-looking data sources are much harder to debug than one well-governed source.
8. Pre-Decision Checklist
Before choosing Sparkplug B, answer these questions.
- Does the platform need to discover devices, edge nodes, and metrics automatically?
- Is the team ready to accept Sparkplug namespace and payload constraints?
- Can the edge gateway generate correct Birth / Death and metric payloads?
- Can the consuming applications parse Sparkplug payloads?
- Is there a clear boundary between Sparkplug B and any existing custom topics?
Before choosing custom topics, answer these questions.
- Is the topic hierarchy documented rather than improvised?
- Does the payload include version, units, timestamp, and quality where needed?
- How are device offline, gateway reconnect, and stale data represented?
- Can a second consumer reuse the same semantics without a private explanation?
- Is there a future path to Sparkplug B or an asset model if the system grows?
The conclusion is that Sparkplug B is best when MQTT becomes part of an industrial data platform. Custom topics are best when MQTT remains a lightweight application messaging channel. A reliable architecture standardizes the boundaries that need collaboration and keeps the rest simple.