Beusa Energy is a 30-year force of disruption in the energy sector, with a family of companies spanning electric hydraulic fracturing, mobile power generation, electrical distribution, field gas processing, and industrial manufacturing. Operating in demanding North American environments with high-frequency telemetry from thousands of remote assets, Beusa initially used a custom MQTT and SQL solution to send data to the Databricks lakehouse. However, the cost-per-GB could not scale economically with their exploding data volumes. To proactively avoid this wall, Beusa sought a new ingestion model to scale seamlessly, eliminate IT overhead, and lower data costs without slowing their operational momentum.
Exploding data volumes expose the limits of a custom SQL pipeline
When Beusa's Data & AI team first built their MQTT-to-lakehouse bridge, Zerobus Ingest didn't yet exist. A .NET 9 worker service subscribed to MQTT brokers across the fleet, parsed JSON and Sparkplug B payloads, and wrote to Delta tables via the SQL Statement API. It shipped quickly, worked reliably, and gave the business its first near-real-time view of operations in the lakehouse. The pain wasn't operational—it was economic. As device counts and data volumes grew, the cost-per-GB on the SQL Statement API path was visibly unsustainable, and the team could see it on the chart before it became a crisis.
"The SQL Statement API is a great tool, but it wasn't designed for high-frequency operational telemetry," said Nick Fornicola, Director of Data & AI Platforms at Beusa Energy. "It got us to production, and it gave us months of runway to prove the use case. But once we knew the workload, we needed an ingestion path purpose-built for it."
The team evaluated two categories of alternatives: managed MQTT brokers with Kafka-compatible interfaces (HiveMQ being the most prominent) and traditional streaming brokers such as Kafka and Azure Event Hubs feeding Databricks via Structured Streaming. HiveMQ's pricing didn't fit their scale and trajectory. The Kafka and Event Hubs path would introduce a stateful broker tier to operate, secure, and pay for on top of the existing Databricks bill. Zerobus Ingest was the only option that allowed direct writes to Delta tables from the existing worker without adding a broker layer. Once they ran the numbers, the choice wasn't close. Beusa saw the wall, did the math, and switched paths before they hit it.
A direct path to the lakehouse, without adding a broker layer
Zerobus Ingest is a direct-write API purpose-built for operational data sources such as IoT, telemetry and clickstreams, where data needs to land in Delta tables continuously, at scale, with seconds of latency. The migration required a single change: swap the SQL Statement API call for the Zerobus gRPC endpoint. Same .NET 9 worker. Same MQTT subscriptions. Same Sparkplug B and JSON payload handling. No device configurations touched.
"We didn't have to rewrite the worker, we didn't change the upstream brokers, and we didn't touch a single device configuration," explained Fornicola. "We swapped the write path, redeployed, and watched the cost curve fall."
Ingestion that had cost roughly 689 DBU per GB on the SQL Statement API path dropped to approximately 0.29 DBU per GB on Zerobus—a reduction of three orders of magnitude on the same workload, same payloads, and same downstream Delta tables. Beusa also avoided standing up a separate streaming broker tier entirely, eliminating an entire class of stateful infrastructure.
Today, more than 6,000 devices stream telemetry at 1 Hz across approximately 250 remote assets into a central lakehouse, with end-to-end latency from sensor to queryable Delta table running around three seconds, governed by Unity Catalog and ready for use the moment it's written.
From cost savings to predictive maintenance at scale
The cost reduction justified the migration, but the broader impact was unlocking scale without an operational headache. Today, Zerobus Ingest effortlessly processes ~22 million rows of telemetry daily with zero maintenance, giving the team a simplified stack and a cost-effective path forward. High-frequency telemetry now feeds cross-functional analytics across operations leadership, fleet management, engineering, and controls and automation—decisions previously made on intuition or lagging reports now driven by unified, near-real-time data.
"Our historian is a great system of record for what happened on a piece of equipment," said Fornicola. "But to answer the questions the business actually asks—across fleets, across basins, across maintenance events—we need that data in the lakehouse, joined with everything else. Zerobus is what makes that economically viable at our scale."
The new architecture also gives Beusa a clear path to advance its maintenance strategy through a defined maturity progression:
Today — Condition-Based Maintenance: Maintenance is triggered by current operating conditions and observed equipment state—better than fixed intervals, but still reactive to what is happening right now.
In Progress — Predictive Maintenance: With high-frequency telemetry now in the lakehouse alongside maintenance history, Beusa is training models to forecast the remaining useful life of each asset. In hydraulic fracturing, high-wear components fail on a curve influenced by dozens of operational variables—pressure, rate, fluid properties, cycles, and more. Modeling those relationships lets the business allocate maintenance time to each asset's actual condition trajectory rather than a fixed schedule.
Next — Prescriptive Maintenance: Once the predictive layer matures, the goal is to move from forecasting failures to recommending actions—automatically reconciling predicted failures against fleet schedules, parts inventory, crew availability, weather, and other operational constraints.
As the fleet expands, the unit economics of ingestion no longer set a ceiling on what data can be captured or what the business can ask of it.
"The lesson for us is not every migration has to save money to be worth it; sometimes it is for reduced operational burden or better latency, sometimes it's both," Fornicola noted. “Zerobus Ingest saved us a lot of money, simplified our stack, and put us on a managed path forward. That's rare."
For Beusa, Zerobus Ingest turned a hard architectural tradeoff into a non-decision. The data flows from the wellsite to the lakehouse in seconds, engineers stopped worrying about the cost of every record written, and the business got a faster path from operational signal to operational action.
