Back to Blog

Microsoft Fabric for Real-Time Analytics - What Works in 2026

May 2, 2026•11 min read•Michael Ridland

Real-time analytics is one of those phrases that gets used loosely. For some teams, "real-time" means a dashboard that refreshes every 15 minutes. For others, it means sub-second latency on a trading floor. Most Australian mid-market organisations sit somewhere in the middle, and that middle ground is exactly where Microsoft Fabric's Real-Time Intelligence workload is at its strongest.

We have now been running Fabric's real-time stack in production with clients for over 18 months. Some workloads have been a clear win. Others have been frustrating. This post is the honest version of what works and what doesn't, written for people who are actively comparing options before signing off on a project.

What People Mean When They Say "Real-Time"

Before getting into Fabric specifically, it is worth being clear about what you actually need. We have lost count of how many times a client said "we need real-time" and the actual requirement was 5 to 15 minute latency on a dashboard.

Here is the rough taxonomy we use in scoping calls:

  • Operational monitoring (5 seconds to 5 minutes latency): equipment status, queue depths, IoT telemetry, application logs. This is Fabric's sweet spot.
  • Streaming analytics (sub-second to a few seconds): fraud detection on payments, real-time bidding, anomaly detection on machine sensors. Fabric handles this, but you need to design carefully.
  • Hard real-time (sub-millisecond): trading systems, industrial control. Fabric is not the right tool. You want something purpose-built like kdb+ or a custom solution.
  • Near real-time reporting (15 minutes to an hour): refreshed dashboards, hourly KPIs. You probably do not need Real-Time Analytics. A regular Power BI dataset with incremental refresh will do.

If your requirement is in the first two buckets, Fabric is worth a serious look. If you are in the last bucket, do not pay for streaming infrastructure you don't need.

The Fabric Real-Time Stack as it Stands in 2026

Microsoft renamed the workload from "Real-Time Analytics" to "Real-Time Intelligence" in late 2024, and the components have matured noticeably since then. The pieces you'll be working with:

Eventstreams handle ingestion. You point them at Event Hubs, IoT Hub, Azure SQL CDC, Kafka, custom apps, or even sample data sources. The UI for routing and transforming streams improved significantly in 2025. We now build most Eventstream flows entirely in the visual designer rather than dropping to code.

KQL Database is the storage and query engine. It is the same Kusto engine that powers Azure Data Explorer. If you know KQL from Azure Monitor or Sentinel, you are 90% of the way there.

Eventhouses group multiple KQL databases under a single capacity. This is a 2024 addition that makes multi-tenant scenarios much cleaner.

Real-Time Dashboards are KQL-native dashboards. Faster than Power BI for streaming data because they query the KQL engine directly without going through the semantic model layer.

Activator (previously Data Activator, previously Reflexes) handles alerting and triggering. When a metric crosses a threshold, it can send Teams messages, kick off Power Automate flows, or hit a webhook.

Eventstream Derived Streams let you split or transform an incoming stream into multiple outputs. This is genuinely useful and changed how we architect ingestion.

Workloads Where Fabric Real-Time Genuinely Works

These are the use cases we keep seeing succeed in real engagements.

IoT and Equipment Telemetry

This is the strongest pattern. A manufacturing client streams sensor data from production lines into Eventstreams, lands it in a KQL database, and runs Real-Time Dashboards on the factory floor for OEE monitoring. The data volume is around 50 million events a day. The dashboards refresh every few seconds. Engineers can drill from a dashboard tile directly into KQL queries to investigate anomalies. It cost them roughly a quarter of what their previous Azure Stream Analytics plus Power BI Premium architecture cost, and the development time was a fraction of the previous build.

Our AI for manufacturing work often starts here, because once you have telemetry flowing properly, applying ML to it becomes straightforward.

Application and System Observability

Streaming application logs and metrics into a KQL database gives you something that looks a lot like Azure Monitor, but with full control over retention and query patterns. We've moved a few clients off third-party observability tools that were billing them $80k to $200k AUD a year, into Fabric KQL databases that cost a fraction of that. The trade-off is you build more of the visualisation layer yourself.

Customer Behaviour Streams for Marketing

E-commerce clients stream clickstream, cart events, and search queries through Eventstreams, land them in KQL, and use Activator to trigger campaigns. One client built a "cart abandonment with intent score" system in three weeks. The intent score was a simple KQL query running every 30 seconds. Before Fabric, they had quoted six months for the same thing on a different stack.

CDC for Operational Reporting

Change Data Capture from Azure SQL or PostgreSQL into Fabric is now solid. We use this pattern when a client has an operational system that needs reporting without hitting the production database. CDC pushes changes through Eventstreams into a Lakehouse or KQL database. Reports run against the replica. The pipeline lag is usually under a minute.

Security and Audit Logs

If you are already paying for Sentinel and want a cheaper analytics layer for the same kind of data, KQL databases in Fabric can hold years of security telemetry at lower cost. We have done this for two clients who needed to retain logs for compliance but did not need the full Sentinel feature set on the older data.

Where Fabric Real-Time Struggles

This is where the marketing pages get quiet, so I will be specific.

Complex Joins on Streaming Data

If your use case needs to join three or four streaming sources together with windowing and state, you can do it in Fabric, but it is harder than it needs to be. The Eventstream visual designer handles simple joins well. Anything more sophisticated and you end up writing materialised views in KQL or pulling data into a Spark Structured Streaming job. Both work. Neither is as smooth as a purpose-built streaming engine like Apache Flink.

Sub-Second Decision Loops

We had a client try to use Fabric for a real-time pricing engine. The requirement was decisions within 200ms. Activator and KQL together could not consistently hit that. We ended up keeping the decision loop in a custom .NET service backed by Redis, and used Fabric for the analytics layer that fed the model retraining. That worked. Trying to make Activator the decision engine did not.

Very High Cardinality Time-Series

KQL handles high-cardinality data reasonably well, but if you have millions of unique IoT device IDs and want to query patterns per device, you can run into performance issues. We've found you need to think carefully about your ingestion partitioning strategy. For some workloads, a purpose-built time-series database like InfluxDB or TimescaleDB is still a better fit.

Streaming ML Inference

You can do inference in Fabric using ML.predict in KQL, but the model loading and refresh story is rougher than what you get with dedicated streaming ML platforms. If you need to swap models frequently or run very heavy models, this is not the right tool.

A Decision Framework

Here is the rough framework we walk clients through:

Question If yes, Fabric is a good fit If no, look elsewhere
Latency requirement is 1 second or higher? Yes If sub-200ms, consider custom
Already invested in Microsoft data stack? Yes If on AWS or GCP, reconsider
Team comfortable with KQL or willing to learn? Yes If only SQL skills, factor in training time
Data volume under 1 TB ingested per day? Yes At very high scale, ADX direct or Snowflake may cost less
Need integrated alerting and dashboards? Yes If you have existing tools, the integration value is lower

If you answered yes to most of these, Fabric Real-Time Intelligence is probably the right choice.

Pricing Reality

A common question we get: how much does this actually cost in production?

The answer is "it depends on your capacity SKU and ingestion volumes," but here are some Australian AUD anchors from real engagements:

  • Small workload (under 5 million events per day, single dashboard, few users): F4 to F8 capacity, roughly $4,000 to $8,000 AUD per month, plus storage which is usually negligible at this scale.
  • Mid-size workload (50 million events per day, multiple dashboards, dozens of users): F32 to F64 capacity, roughly $20,000 to $40,000 AUD per month.
  • Large workload (hundreds of millions of events per day, complex KQL workloads, hundreds of users): F128 and up. Once you cross F128, you are in serious enterprise pricing territory and should be having explicit cost conversations with Microsoft.

Compare this to Azure Stream Analytics plus ADX plus Power BI Premium for an equivalent workload, and Fabric usually wins on total cost. The savings come from consolidating SKUs and from not paying for over-provisioned dedicated services.

For a deeper view, our Microsoft Fabric pricing guide for Australia covers SKU sizing in more detail.

Common Mistakes We See

A few patterns that keep tripping people up:

Treating KQL like SQL. KQL has its own idioms. Writing it like SQL gives you slow queries. The biggest wins come from using summarize, materialize, and the lookup operator correctly. Plan for some KQL training, especially if your team only knows T-SQL.

Over-engineering the ingestion layer. We have seen teams build elaborate Eventstream pipelines with five or six transformation steps when they really just needed to land raw data and transform in KQL. Land first, transform later. KQL is fast enough that you rarely need to pre-transform.

Ignoring capacity smoothing. Fabric does capacity smoothing across hours, but if you have very spiky workloads you can still hit throttling. Monitor capacity utilisation actively in the first few weeks.

Building reports in Power BI when Real-Time Dashboards would be better. If your audience needs streaming data, build the dashboard in the Real-Time Intelligence workload. Power BI works, but it does not refresh fast enough for genuine real-time monitoring.

Forgetting about retention policies. KQL databases need explicit retention configuration. Default is 100 years. Set it to what you actually need or you'll be storing data forever and paying for it.

What Good Looks Like for a First Project

If you are about to start your first Real-Time Intelligence build, here is what a realistic first project looks like:

  • One ingestion source (an Event Hub or an Azure SQL CDC feed)
  • One KQL database with 2 to 3 tables
  • One Real-Time Dashboard with 5 to 10 tiles
  • One or two Activator rules
  • 4 to 6 weeks from kick-off to production, including a discovery phase

If someone is quoting you 12 weeks for that scope, they are overcomplicating it. If they are quoting you 2 weeks, they are skipping discovery. Neither is a good sign.

When to Bring in a Consultant

Some teams can stand this up themselves. If you have an engineer who already knows KQL and Azure, the platform is approachable. The Microsoft Learn material is genuinely good for Real-Time Intelligence specifically.

Where consultants add value:

  • You have a streaming requirement but no existing KQL skills, and you need to be productive quickly.
  • You are picking between Fabric, Snowflake Streams, Databricks Structured Streaming, or a custom build, and you need an honest comparison from someone who has done all of them.
  • You need to integrate Real-Time Intelligence with your existing Lakehouse and Power BI environment without creating a mess.
  • You are sceptical that the project will hit the latency or cost targets you've been promised, and you want a second opinion before signing the SOW.

That last one is more common than you might think. We get called in fairly often to review proposals from other firms before clients commit. Sometimes we say "this looks fine, go ahead." Sometimes we save them from a bad architecture decision.

Final Take

Microsoft Fabric Real-Time Intelligence in 2026 is genuinely good for the workloads it is designed for. The platform has matured, the cost story makes sense for mid-market organisations, and the integration with the rest of Fabric makes it easy to combine streaming and batch analytics.

But it is not magic. You still need to understand your latency requirements, choose the right patterns, and have someone who knows KQL on the team. The platform makes the easy things easy and the hard things possible. It does not make the hard things easy.

If you are sizing up a real-time analytics project and want a candid view on whether Fabric is the right tool, get in touch. We work with Australian organisations on Microsoft Fabric consulting engagements and have walked plenty of clients through this exact decision. You can contact us or read more about how we work with mid-market organisations.