Industrial IoT Manufacturing · Heavy machinery Customer Story

Modernizing an Industrial IoT data stack for processing machine sensor data

€3B Annual revenue machine builder
400GB Compressed data per day at peak
Real-time Processing, replacing batch jobs

A €3 billion machine builder designs and builds heavy machinery for the metals industry. When InfluxDB deprecated the Flux query language, the team behind its sensor-data pipeline had a choice to make — and used it as an opportunity to move from batch processing to real time.

The challenge

The company's data processing had grown organically: proprietary PLC solutions (Siemens S7) buffered data to a central InfluxDB via Telegraf, Grafana handled visualizations, and statistical analysis ran as scheduled Flux tasks. In 2023, InfluxDB deprecated Flux in favour of SQL — and the team quickly recognized that SQL would produce unwieldy code for the statistics, multiplication and division their analysis depended on.

It's not complicated what we do, but we do need to do some statistics, some multiplication, some division. SQL code is not going to be nice. Python is the way to go.

IIoT Specialist — €3B Industrial Machine Builder

Python was the obvious answer, but InfluxDB has no native Python task support, and orchestrators like Apache Airflow and Prefect felt far too heavy for a team with limited data-engineering capacity. That gap pushed the search toward streaming.

The solution

The IIoT specialist discovered Quix through an InfluxDB webinar. Early skepticism about streaming complexity dissolved once it was clear how much Quix stripped away.

First of all, I said we don't need streaming. It's too complex. But if tools are stripped down so we don't deal with all that complexity, then it's an option.

IIoT Specialist — €3B Industrial Machine Builder

The decisive factors were a Python-first architecture, built-in windowing for segmenting machine cycles, usage-based pricing suited to a pilot, containerized processes that prevent resource overruns, edge processing via the open-source Quix Streams SDK, and MQTT support for remote, unreliable connectivity. The migration itself was straightforward: the team spun up a Quix Cloud account with built-in Kafka, used the Quix InfluxDB connector to poll and stream data into Kafka topics, converted each Flux query into a continuously running Python process in a containerized deployment, and wrote the calculated results back to InfluxDB.

The results

Batch Flux jobs on the server gave way to real-time analysis on a managed platform, offloading processing from InfluxDB entirely. The new flow runs raw data through Telegraf and an MQTT broker into Quix Streams for Kafka ingestion, analyzes it as it arrives, and stores the results back in InfluxDB.

Next on the roadmap is wider MQTT adoption to bridge globally distributed machinery with patchy connectivity, and — within two years — deploying Quix containers onto edge hardware such as Revolution Pi devices for lower latency, optimized bandwidth and stronger security. The specialist frames the shift to real time as "a bet into the future," on the principle that data is most valuable closest to its source.

Moving data around is not easy. We collect up to 400 GB of compressed Influx files per day at the biggest plants. Moving that with scripts was impossible.

IIoT Specialist — €3B Industrial Machine Builder

Stop building infrastructure. Start engineering.

BOOK A DEMO