If your "plant" is actually fifty pump stations, wells and tanks spread across a county on cellular modems, traditional polling is the wrong tool. Polling every site for every value over a metered link is slow, expensive and brittle. MQTT with the Sparkplug specification flips the model to report-by-exception, and it's the backbone of most modern water-district and IIoT systems we build on Ignition.
What MQTT and Sparkplug are
MQTT is a lightweight publish/subscribe messaging protocol: edge devices publish data to a central broker, and consumers subscribe — no point-to-point polling. Sparkplug B is an open specification on top of MQTT that standardizes how industrial data is structured and, critically, adds birth and death certificates so the system always knows whether a device is alive. That state awareness is what makes MQTT trustworthy for SCADA rather than just telemetry.
Why it fits water and remote sites
Report-by-exception means a site only sends data when something changes, which slashes cellular data usage versus constant polling. Birth/death certificates turn "is that station online?" into an instant, unambiguous answer instead of a guess based on stale values. And the pub/sub model decouples sites from the central system — you add a station by pointing it at the broker, not by reconfiguring a central poller. For a fleet of unmanned sites, that's transformative. (It's the data layer behind the patterns in our guide to remote plant and water-district monitoring.)
The architecture on Ignition
A typical build: an edge gateway or device at each site (Ignition Edge or a Sparkplug-capable RTU) reads the local PLC and publishes to a broker; the central Ignition gateway subscribes and becomes the system of record, history and operator UI. Ignition's MQTT modules (Cirrus Link's Transmission at the edge, Engine at the center, and a Distributor broker, or your own broker) handle the Sparkplug plumbing so tags flow into the central tag tree automatically.
Store-and-forward and quality of service
Remote links drop — the design must assume it. Edge store-and-forward buffers data locally during an outage and backfills when the link returns, so history has no holes. MQTT QoS levels and Sparkplug's session model make sure messages aren't silently lost. On screen, a clear "last good data" indicator keeps operators honest about what's live versus stale.
Security
Putting infrastructure on a public cellular network raises the stakes: TLS encryption on every connection, per-device credentials or certificates at the broker, and network segmentation so a compromised modem can't reach more than it should. Sparkplug's structured topics also make it straightforward to scope what each site can publish.
When OPC UA is still the right call
MQTT isn't a religion. For a single wired plant where the gateway and PLCs share a reliable LAN, OPC UA polling is simpler and entirely appropriate — there's no bandwidth problem to solve. Reach for MQTT/Sparkplug when sites are distributed, links are metered or unreliable, or you're building toward a broader IIoT/unified-namespace architecture.
Where we come in
We design and deploy MQTT/Sparkplug architectures on Ignition for water districts, irrigation systems and distributed IIoT across California's Central Valley and remotely nationwide. To scope a connected-sites project, get in touch or see our Ignition development services. Not sure MQTT vs polling is even the question? Start with choosing the right integrator.