Microsoft Fabric’s Real-Time Intelligence provides a tenant-wide pipeline to ingest, analyse and act on streaming data in near real time. It unifies four capabilities into one flow: ingest through Eventstreams, store and query in Eventhouse, visualise through dashboards, and act through Activator. The Real-Time Hub sits above all of it, automatically provisioned in every Fabric tenant with no setup required.
TL;DR:
- Eventhouse only mirrors to OneLake when explicitly enabled, making cross-engine access dependent on active configuration.
- Autosuspend delays for cost savings can cause minor lag in data availability, especially with bursty or irregular streams.
- Building a real-time fabric requires early decisions on ingestion mode, including enabling cross-engine access, before production deployment.
- Monitoring capacity usage weekly and setting lifecycle policies helps prevent unexpected cost spikes and capacity drain.
- Moving from Synapse Data Explorer to Eventhouse involves a migration window of up to 90 days, with a focus on validating and redirecting endpoints.
Table of Contents
- Core components and how data flows through the fabric
- Architecture patterns and typical use cases
- Capacity, billing and performance trade-offs
- Implementation checklist and best practices
- Practitioner insights and common pitfalls
- When to build in-house and when to bring in a specialist
- How Datataal helps you put this into production
- Where to go for authoritative documentation
- Sources
- FAQ
Core components and how data flows through the fabric
Each part of Real-Time Intelligence has a distinct job, and understanding the handoffs between them matters more than memorising any single feature.
The Real-Time Hub is a tenant-wide, single logical place for streaming data in motion. Every stream, regardless of which workspace created it, becomes discoverable here, which solves a common problem in growing organisations: nobody knowing what streaming sources already exist.
Eventstreams handle ingestion. They support a wide range of connectors, no-code transformations, and DeltaFlow, which converts change data capture streams into an analytics-ready shape with automatic schema registration. That last point saves engineering hours on projects where source systems change schema without warning.
Eventhouse is where streaming data lands for querying. It is a database optimised for time-based events, built to handle billions of records with indexing that keeps query response fast. Eventhouses also autosuspend when idle to control cost, and can mirror their contents to OneLake for cross-engine access when that option is switched on.
Querying happens through KQL querysets, and KQL remains the primary language. SQL-familiar analysts are not locked out, though: querysets accept T-SQL as well, so teams do not need to retrain everyone before they can query streaming data.
Real-time dashboards, made generally available through the Fabric blog announcement, refresh as often as every 10 seconds or update continuously. Dashboard permissions are managed separately from the underlying data, which keeps sensitive datasets protected even when a dashboard is shared broadly.
Practical implications worth flagging early:
- Eventhouse mirrors to OneLake only when OneLake availability is explicitly enabled, not by default.
- Explore Data gives analysts a no-code way to inspect streaming datasets before building a formal dashboard.
- KQL querysets bridge KQL and T-SQL, so reporting teams keep working in familiar syntax.
Architecture patterns and typical use cases
Most real-time analytics fabric deployments fall into a handful of recognisable patterns.
- Operational monitoring: an Eventstream feeds Eventhouse, a real-time dashboard visualises the incoming metrics, and Activator triggers alerts when thresholds are breached. This suits factory floors, network operations centres and fraud monitoring.
- Hybrid analytics: Eventhouse handles immediate operational queries while a OneLake mirror feeds a lakehouse for machine learning training and long-term historical analysis. This avoids duplicating ingestion logic for two very different consumption patterns.
- Digital twin and geospatial monitoring: streaming telemetry combined with map integration suits fleet tracking, utilities and logistics, where location and time both matter to the decision being made.
- Migration from Synapse Data Explorer: organisations retiring Synapse Data Explorer clusters can move to Eventhouse, with endpoints redirecting for up to 90 days after migration, using the Fabric REST API to validate, migrate, monitor and verify each cluster.
Choosing between these patterns comes down to one question: does the business need to react within seconds, or does it need to understand trends over weeks? Real-time and right-time analytics both belong in a mature architecture, and Fabric supports switching between them without rebuilding ingestion.
Capacity, billing and performance trade-offs
Cost in Real-Time Intelligence tracks activity, not just storage. Query executions, Anomaly Detector runs and operations agents all draw from Capacity Units, and billing for Anomaly Detector is tied to each query execution, with operations agents and Copilot metered separately in the Capacity Metrics app.
Autosuspend on Eventhouse lowers cost but adds a small reactivation delay measured in seconds, according to Microsoft’s Eventhouse documentation, which matters when an SLA cannot tolerate any lag.
Practical controls worth setting from day one:
- Use Capacity Planner with a scheduled minimum to stop autoscale dropping below a guaranteed baseline during business-critical windows.
- Watch CU consumption trends in the Capacity Metrics app rather than discovering a spike at invoice time.
- Treat OneLake mirroring and adaptive batching as levers: more frequent mirroring raises freshness but also raises cost.
Implementation checklist and best practices
A production-grade real-time analytics fabric benefits from a short, disciplined sequence of decisions rather than an open-ended build.
- Decide early whether Direct Lake or a cross-engine SQL endpoint is needed. If so, enable OneLake availability on the Eventhouse or KQL database, since it is not on by default.
- Choose an ingestion mode deliberately. DeltaFlow is the right tool when change data capture streams need an analytics-ready shape without heavy custom transformation logic.
- Set partitioning, mirroring policy and small-file controls before data volume grows. Poorly tuned mirroring produces excessive small files in OneLake and slows downstream queries.
- Apply Capacity Planner wherever a business SLA demands strict latency, and monitor consumption continuously rather than reactively.
- Separate dashboard permissions from data permissions so a widely shared dashboard never becomes an unintended data leak.
Teams building their first Eventstream often benefit from a structured walkthrough of connectors and transformation options, covered in this guide to creating Eventstreams.
Pro Tip: Enable OneLake availability before your first production dashboard ships, not after; retrofitting it later means re-validating every downstream query against the new Delta Lake representation.
Practitioner insights and common pitfalls
OneLake availability is the single most overlooked setting in Real-Time Intelligence. Leave it off and your Eventhouse data stays locked inside the KQL engine, invisible to Power BI Direct Lake and Fabric notebooks, which frustrates analysts who assumed everything in Fabric was automatically cross-engine.
Eventhouse’s autosuspend behaviour is efficient for cost but sensitive to ingestion patterns: bursty, irregular streams trigger more suspend and resume cycles than a steady feed, each adding a short delay.
A pattern that holds up well in practice: stream raw events into Eventhouse for immediate querying, then mirror selected datasets into OneLake for machine learning and retention, rather than building two separate ingestion paths.
- Separate who can view a dashboard from who can query the underlying Eventhouse.
- Monitor CU spend weekly, not at billing time.
- Set a lifecycle policy for operations agents so unused ones stop consuming capacity silently.
When to build in-house and when to bring in a specialist
An internal team is ready to run real-time analytics once it has KQL or T-SQL skills, clear ownership of capacity governance, and the discipline to monitor CU spend continuously. When the goal is a migration, a strict SLA, or enabling cross-engine access across several teams at once, a phased engagement with a specialist tends to move faster and avoid rework. Done well, the payoff is faster incident detection and less manual firefighting.
— Michael
How Datataal helps you put this into production
I work directly with organisations that want their Fabric real-time analytics fabric built once, correctly, rather than patched together under deadline pressure. That means Fabric architecture design, Eventstream and Eventhouse implementation, OneLake and DeltaFlow enablement, and real-time dashboards built to match the business questions you actually ask, not generic templates.
Engagements run in phases: an architecture assessment, a build phase covering ingestion and Eventhouse configuration, and a governance handover so your team owns capacity monitoring and dashboard security from day one. I also train internal staff so the fabric stays maintainable after the project ends, rather than depending on outside help indefinitely.
If your organisation is migrating from Synapse Data Explorer, enabling cross-engine access for the first time, or simply tired of dashboards that lag behind what is actually happening on the floor, my Microsoft Fabric consulting services page outlines how engagements are scoped, starting from $20 per hour.
Where to go for authoritative documentation
For hands-on reference, start with the Real-Time Intelligence overview, the Eventhouse documentation, and Microsoft’s guidance on migrating Synapse Data Explorer clusters. Teams evaluating real-time dashboards for operational use may also find this external case study on agent analytics a useful comparison point.
Sources
- Real‑Time hub in Fabric documentation – Microsoft Learn
- Announcing Real‑Time Dashboards generally available – Microsoft Fabric Blog
FAQ
What is real-time analytics?
Real-time analytics is the practice of processing and analysing data as it is generated, rather than waiting for a scheduled batch job. In Microsoft Fabric, this happens through Eventstreams feeding Eventhouse, with dashboards refreshing as often as every 10 seconds.
Is service Fabric deprecated?
Azure Service Fabric, the older container orchestration platform, is a separate product from Microsoft Fabric, the data analytics platform this article covers. Microsoft Fabric’s Real-Time Intelligence, including Eventhouse and Real-Time Hub, is an actively developed part of the platform, not a deprecated feature.
How much does MS Fabric cost?
Pricing for Microsoft Fabric depends on capacity size and usage, including Capacity Unit consumption from queries, Anomaly Detector runs and operations agents, tracked through the Capacity Metrics app. Datataal’s Microsoft Fabric consulting services for implementation and architecture work start from $20 per hour.
What is Fabric in data analytics?
Microsoft Fabric is a unified data platform that combines ingestion, storage, engineering, real-time analytics and business intelligence in one environment. Its Real-Time Intelligence component, covering Eventstreams and Eventhouse, handles data that needs analysis within seconds rather than hours.
