Telemetry That Talks Back: Real-Time Intelligence for Sensor-Heavy Operations

The Executive Insight

Every previous issue in this run assumed your data arrives in batches: a nightly refresh, a scheduled pipeline, a report that’s current as of this morning. For a lot of mid-market operations, that model is fine.

For anyone running physical operations, it isn’t. An oil and gas operator pulling SCADA readings off wellheads and compressor stations, or a manufacturer watching line telemetry across plants, doesn’t have a “this morning” problem. They have a “right now” problem: a pressure reading trending the wrong way, a motor drawing more current than it did an hour ago, a line about to breach tolerance. By the time that shows up in tomorrow’s dashboard, the event is over and the cost is booked.

Fabric has a distinct answer for this, and it’s worth understanding as its own thing rather than a faster version of your BI stack. This issue is about Real-Time Intelligence: the parts of Fabric built specifically for data in motion, and why sensor-heavy verticals are where it earns its place.

The Wrong Tool and the Right One

A common and expensive mistake is to try to force high-frequency telemetry through your normal analytics path: land it in a lakehouse, run it through refresh cycles, report on it in Power BI. It technically works, and it’s the wrong architecture.

The reason is mechanical. Streaming sensor data arriving continuously produces a proliferation of tiny files, which degrades the performance of batch-oriented engines and forces constant maintenance to stay usable. The batch stack was built for volume that arrives on a schedule, not a firehose that never stops.

Real-Time Intelligence is Fabric’s purpose-built lane for this. Microsoft is explicit that actual real-time analysis belongs on the streaming engine rather than the batch one. Two components carry most of the weight, and understanding the split between them is the whole point.

Eventstream: Getting the Firehose In

Eventstream is the ingestion and routing layer. It brings real-time events into Fabric, optionally transforms them in flight, and routes them to destinations, all through a no-code drag-and-drop canvas rather than hand-written streaming code.

For sensor-heavy operations, three properties matter.

It speaks the protocols your operational estate already uses. Eventstream exposes an Apache Kafka endpoint and connects to sources like Azure IoT Hub, which is often how SCADA and plant telemetry already reach the cloud. You’re connecting to infrastructure your OT team likely already runs, not replacing it.

It transforms before it lands. You can filter, aggregate, and reshape the stream in flight, for example collapsing a raw per-second sensor feed into a windowed average before it’s ever stored, which cuts noise and cost at the same time.

It fans out to multiple destinations at once. The same stream can drive a live operational view, land in an Eventhouse for analysis, and trigger an alert, without those consumers interfering with each other.

Eventhouse: Querying Billions of Events in Seconds

Eventhouse is the storage and analytics engine, purpose-built for time-series and streaming data. It’s a database designed to store and analyze streaming events so you can query billions of them in seconds, automatically organizing incoming data for fast retrieval based on when it arrived. You query it with KQL (Kusto Query Language), which is built for exactly the “what happened across these sensors in the last ten minutes, and how does that compare to the last ten days” questions that operational analytics lives on.

Two things make it a fit for lean operations specifically.

It’s designed to optimize cost by suspending when idle, spinning back up within seconds on demand. For genuinely time-critical systems that can’t tolerate even that brief spin-up, you can schedule a guaranteed baseline of capacity during the windows that matter (say, production hours) and let it stay elastic the rest of the time. You pay for always-on only where always-on actually earns it.

And it has its own throttling model tuned for not losing data. When capacity limits are hit, the first response throttles queries while ingestion keeps running, so you can be slow to answer without dropping the incoming readings. That ordering, protect the data first, is exactly what you want in an operational context.

What This Looks Like in the Field

Put together, a sensor-heavy pattern reads like this.

Wellhead or line telemetry flows through IoT Hub or a Kafka endpoint into an Eventstream. In flight, the stream is filtered and aggregated: raw high-frequency readings collapsed into windowed metrics, obvious noise dropped. The stream fans out. One branch lands in an Eventhouse, where KQL powers a live operational dashboard and supports historical queries across weeks of readings for pattern analysis. Another branch feeds Activator, Fabric’s trigger engine, which watches for a defined condition, a pressure threshold crossed, a temperature out of band, and fires an alert or kicks off a downstream action automatically.

The result is telemetry that talks back: not a report you check, but a system that tells you when something’s moving before it becomes an incident.

Hope for Lean Teams

You don’t need an OT data engineering team to start here. The path is narrower than it looks.

Pick one signal that actually drives an operational decision, a single critical pressure, temperature, or throughput reading, rather than trying to onboard every sensor at once. Route it through an Eventstream with a simple in-flight aggregation into an Eventhouse. Build one KQL-backed real-time view of that signal, and wire one Activator rule to the threshold that matters. That’s a complete, working real-time loop for one decision, standing on infrastructure your operations team likely already feeds. You can repeat it signal by signal from there, without ever standing up a bespoke streaming platform.

Where I Fit In

Real-Time Intelligence is where the gap between “we have the data” and “we act on it in time” gets closed, and the architecture choices, what to aggregate in flight, what to persist, where to set the thresholds, when to guarantee baseline capacity, are what separate a system that prevents incidents from one that just records them.

If you’re sitting on a stream of SCADA or plant telemetry that today only becomes useful the next morning, and you want it driving decisions in the moment instead, let’s talk.

Batch analytics tells you what happened. For operations running on sensors, that’s often one shift too late. Real-Time Intelligence is the part of Fabric built to tell you while you can still do something about it.

Next week, we shift from the edge back to the model: large semantic models and refresh mechanics, and the modeling choices that save a refresh window.

Isaac Truong | Founder, Allston Yale

Enterprise-grade analytics for $50M–$100M SMBs

Power BI | Fabric | Azure | Data Strategy

Book a 20-min Fabric diagnostic →

Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates)

LinkedIn: Connect with me for daily Fabric tips

Friday Fabric Facts #24: Originally Posted on LinkedIn, July 10, 2026