Data Panda brings the topics, retained messages and broker telemetry flowing through your MQTT broker together with the data from the rest of your business. From one place, we turn it into dashboards, automations, AI workflows and custom apps your team uses every day.
MQTT is a publish-subscribe messaging protocol designed to move small messages between many clients over unreliable, low-bandwidth networks. Clients publish to hierarchical topics like plant/line-3/temperature, the broker routes those messages to whichever clients have a matching subscription, and the wire format is small enough that a minimal control packet fits in two bytes. Three QoS levels (at most once, at least once, exactly once), retained messages and last-will messages give the protocol enough reliability primitives to survive flaky satellite, cellular and field networks without a heavyweight transport.
It started in 1999 at IBM, where Andy Stanford-Clark and Arlen Nipper (then at Cirrus Link) built it to monitor an oil pipeline over satellite. The acronym originally meant MQ Telemetry Transport, and was officially retired in 2013 once the protocol outgrew its original SCADA roots. OASIS published MQTT 3.1.1 as a standard in October 2014 and MQTT 5.0 in March 2019. Today it sits underneath fleet, manufacturing, smart-building, automotive, energy and consumer-IoT stacks, on brokers like Eclipse Mosquitto, HiveMQ, EMQX, AWS IoT Core and Azure IoT Hub.
The point of pulling MQTT into a warehouse is not to land every device payload, those are usually high-frequency and belong on the hot path between sensor and control loop. It is to make the broker layer visible: connected-client counts, message rate per topic branch, retained-message age, dropped-message counts per QoS, last-will fires per device class, bytes in and out per gateway. That data sits next to ERP production runs, CRM accounts and field-service tickets, and the question of why a line stopped pushing readings on Tuesday stops being a guess between firmware, network and broker.
MQTT-broker- en topic-telemetrie gekoppeld aan ERP, CRM en field-service in SQL.
Let MQTT signals fire actions across the rest of the stack.
Use broker and device telemetry to score behaviour and predict where the next outage forms.
Internal tools that read MQTT telemetry without broker-console access.
A list of concrete reports, automations and AI features we have built on MQTT data. Pick the one that matches your situation.
Why did line 3 stop sending readings on Tuesday morning?
Connected-client count, message rate per topic branch, last-will fires and retained-message age plotted on the same timeline as production runs, network events and firmware deploys. The Tuesday gap stops being a finger-pointing match between firmware, network and broker, and becomes a chart maintenance, IT and operations all read the same way.
Which device-class drives the most last-will fires?
Last-will events broken down by device-class, firmware version, gateway and site. Surfaces the firmware build that quietly drops a TCP keep-alive every few hours, the gateway with a flaky cellular link, and the site where the install crew still has the old image. The conversation with the device vendor stops being anecdotal.
What does our IoT estate cost us per customer?
Broker spend, cellular bytes per gateway and connected-client count joined to the customer record in the warehouse. The IoT line gets a per-customer denominator, and account managers can talk concretely about which installs drive the next broker tier or SIM-plan upgrade.
Broker spend and cellular cost tied to message volume, gateway and customer. The IoT line stops being a flat infrastructure cost and gets a per-customer denominator finance can defend in the budget review.
Per-customer connected-device count, uptime and message volume surfaced on the CRM account. Account managers can talk concretely about SLA, plan limits and upgrade triggers without waiting for engineering to dig the numbers out of the broker console.
Connected-client counts, topic gaps, last-will fires and retained-message age kept in one place across firmware deploys and network events. The field-service ticket starts from a chart, not a phone call from the customer.
You keep the reporting tool you already have. We connect it to the warehouse where your MQTT data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
No, and that is on purpose. Device payloads are usually high-frequency and belong on the hot path between sensor and control loop. We pull broker-side metadata: connected-client counts, message rate per topic branch and QoS, retained-message age, last-will fires, bytes in and out per gateway. That metadata is what answers fleet, capacity and SLA questions. If a specific topic carries readings you do want as queryable history, we tee those off explicitly per topic, with retention and downsampling rules attached.
We pull broker stats from the system topics or admin API the broker already exposes (Mosquitto's $SYS branch, the HiveMQ and EMQX management APIs, AWS IoT and Azure IoT Hub metrics endpoints). For per-topic volume we sample rather than mirror every message, scoped per topic filter, and we cache locally so a warehouse refresh does not multiply the load. On high-volume brokers we lean on the metrics the broker already aggregates rather than fanning out per-client calls.
We review your MQTT setup and the systems around it. Together we pick the first thing worth building.