What is Eventhouse in Microsoft Fabric?

Eventhouse is Fabric's KQL-backed columnar store optimized for time-series and high-cardinality queries — the underlying storage engine for Real-Time Intelligence. Eventhouse is evolved from Azure Data Explorer (ADX) technology, so KQL syntax, ingestion patterns, and query semantics are largely compatible. Eventhouse databases hold streaming event tables partitioned by ingest time; materialized views pre-compute common aggregations on ingest for 10-100x query speedup on dashboard workloads.

When should I use Fabric RTI vs Power BI?

Use Fabric RTI when: data velocity exceeds 1000 events/second sustained, query latency requirement is under 5 seconds against last 24 hours, time-series or high-cardinality (100k+ distinct values) query patterns, or you need sub-second dashboard refresh. Use Power BI (Import or Direct Lake+) when: batch analytics with hourly or daily refresh fits, historical analytical exploration is the primary use case, or you need Copilot narration on the same semantic model. Many enterprises use both — RTI for operational dashboards, Power BI for analytical.

How much does Fabric Real-Time Intelligence cost?

Fabric RTI shares the F-SKU CU pool with Power BI, Data Engineering, and Copilot. RTI cost depends on event volume: 500 events/second uses ~10 CU-seconds/second (10% of F64); 3000 events/second uses ~25 CU-seconds/second (39% of F64); 20,000 events/second SIEM workload uses ~120 CU-seconds/second (needs F128); 50,000 events/second trading workload needs F256+. F64 monthly costs $8,409.60 pay-as-you-go or $5,002.67 with 1-year reserved. Isolate RTI to a dedicated F-SKU for volume workloads to protect BI query CU.

What is KQL in Fabric?

KQL (Kusto Query Language) is Microsoft's proprietary query language optimized for streaming and time-series analytics, used in Fabric Real-Time Intelligence, Azure Data Explorer, Azure Monitor, and Microsoft Sentinel. KQL syntax uses pipeline operators: `Events | where Timestamp > ago(1h) | summarize Count = count() by bin(Timestamp, 1m) | render timechart` filters, aggregates, buckets by minute, and renders a chart in one query. Key operators: where, summarize, project, join, bin, ago, render, make-series, series_decompose, autocluster.

Can Fabric RTI replace Kafka and ClickHouse?

Yes for many enterprise use cases — Fabric RTI is Microsoft's answer to the Kafka + ClickHouse + Grafana stack that enterprises typically stitch together for real-time analytics. Eventstream replaces Kafka ingestion pipelines with declarative configuration; Eventhouse replaces ClickHouse with KQL-backed columnar storage; Real-Time Dashboards replace Grafana with native Fabric visualization. Advantages over the stitched stack: unified Fabric F-SKU billing, Copilot integration on streaming data, Purview lineage tracking, and no infrastructure to manage. Not a fit for sub-100ms latency workloads (use Cosmos DB) or SQL-Server-compatible tooling (use Fabric Data Warehouse).

How is a Power BI engagement priced for enterprise workloads?

Pricing is modeled against three variables: the complexity of the semantic layer, the volume and velocity of source data, and the governance footprint required after go-live. A scoped implementation typically runs as a fixed-fee discovery sprint followed by a time-and-materials build, because dataset refresh patterns and row-level security rules almost always evolve once real user personas review early drafts. Licensing is separated from consulting fees and mapped against Power BI Pro, Premium Per User, and Fabric capacity SKUs so finance teams can plan capacity uplift independently of delivery cost. A typical mid-market rollout lands between 120 and 480 consulting hours across data modeling, DAX optimization, report design, and deployment pipelines. Fabric workloads add capacity sizing sessions to avoid over-provisioning F-SKUs on day one.

How long does a production-ready Power BI rollout take?

A single subject-area workspace with a conformed star schema, deployment pipeline, and row-level security ships in roughly six to eight weeks once source access is granted. Multi-domain rollouts that span finance, operations, and customer analytics typically run three to five months because the semantic model has to reconcile calendar, product, and organizational hierarchies that rarely align across source systems. Fabric lakehouse projects add four to six weeks for medallion design, Direct Lake tuning, and OneLake shortcut setup. Timelines compress when an authoritative data dictionary already exists and lengthen when stakeholders are discovering definitions (for example, what counts as "active customer") for the first time. Governance, training, and center-of-excellence enablement are run in parallel rather than sequentially.

What delivery methodology do you use for Power BI and Fabric projects?

Delivery runs on a five-stage pattern: Discover, Model, Visualize, Operationalize, and Enable. Discover captures questions stakeholders actually want answered, not just source tables. Model builds a Kimball-style star schema (or a medallion lakehouse in Fabric) with conformed dimensions and documented grains. Visualize produces reports against a shared theme file, applies accessibility tokens, and uses bookmarks and field parameters instead of bespoke page duplication. Operationalize wires up deployment pipelines, dataset refresh monitoring, and Azure DevOps or GitHub source control via TMDL. Enable delivers hands-on training for citizen developers and a lightweight center-of-excellence charter. Each stage ends with a demo and a written acceptance checklist, so scope creep is visible before it becomes rework.

How do you secure sensitive data inside Power BI reports?

Security is layered rather than relying on a single control. Row-level security and object-level security are enforced inside the semantic model using DAX filter expressions driven by Entra ID group membership, so filters survive refresh and cannot be bypassed by report-level tricks. Sensitivity labels from Microsoft Purview are applied at dataset and report scope and follow exports into Excel and PDF. Workspace roles follow a least-privilege pattern (Admin, Member, Contributor, Viewer) and are granted to Entra ID groups, never individuals. Private endpoints and VNet data gateways keep on-premises sources off the public internet, and tenant-level settings restrict publish-to-web, external sharing, and guest access. Every production dataset is audited quarterly against a written RLS test plan.

Can existing Excel and Tableau reports be migrated into Power BI?

Yes, but a migration is an opportunity to redesign rather than a literal port. Excel financial models usually translate cleanly into a semantic model: named ranges become dimensions, pivot tables become matrix visuals, and SUMIFS chains become well-formed DAX measures with variables. Tableau workbooks require more interpretation because Tableau extracts and Power BI datasets have different refresh and relationship semantics; calculated fields are rewritten as DAX, LOD expressions become CALCULATE patterns, and dashboard actions are rebuilt using bookmarks and drillthrough. A discovery audit catalogs every report, ranks them by business value, and retires the long tail of duplicates before migration starts. This typically reduces the report estate by 30–50 percent.

How do you optimize DAX performance on large semantic models?

DAX performance starts with the model, not the measure. Star schemas with integer surrogate keys, single-direction relationships, and calculated columns materialized in Power Query outperform ambiguous snowflakes every time. Measures are written using variables (VAR/RETURN) to avoid repeated context transitions, and expensive patterns like FILTER over entire tables are replaced with KEEPFILTERS and Boolean filter arguments. Aggregation tables and composite models offload detail-level queries from imported caches to Direct Lake or DirectQuery sources. Every measure that appears in a production report is profiled with DAX Studio and VertiPaq Analyzer; queries above a 2-second threshold on representative hardware are rewritten before release. Fabric capacity metrics are reviewed weekly to catch runaway refreshes and interactive CPU spikes.

Do you support Microsoft Fabric, OneLake, and Direct Lake workloads?

Fabric is now the default landing zone for new analytics workloads unless a client has a specific reason to stay on legacy Power BI Premium capacity. Engagements cover medallion architecture design in lakehouses, data engineering pipelines built in Fabric notebooks or Dataflows Gen2, shortcut-based integration with Azure Data Lake Storage and Amazon S3 through OneLake, and Direct Lake semantic models that skip import refresh entirely. Capacity sizing is based on measured workload patterns rather than vendor rules of thumb, and F-SKU scaling is automated through Azure Logic Apps or the Fabric REST API so off-hours costs stay predictable. Copilot in Fabric is configured with tenant-level data boundaries and audit logging before it is enabled for end users.

What training and enablement do end users receive after go-live?

Training is tiered by persona. Report consumers get a 45-minute guided tour covering filters, bookmarks, subscriptions, and mobile access. Analysts get a three-session workshop on self-service semantic model extensions, composite models, and publishing to workspaces that follow the governance pattern. Data modelers receive a two-day immersion on star schema design, DAX fundamentals, and deployment pipeline usage. Every session is recorded, indexed, and paired with a sandbox workspace seeded with representative sample data. A written center-of-excellence charter defines who owns certified datasets, who can promote a report to production, and how to request enhancements. Office hours run for 30 days post-launch so questions do not pile up into a formal change request.

How are Power BI deployments managed across dev, test, and production?

Every production workspace is paired with matching development and test workspaces wired through Power BI deployment pipelines. Datasets are source-controlled as TMDL files in Azure DevOps or GitHub so pull requests can be reviewed by a second modeler before merge. Environment-specific parameters (connection strings, sensitivity label rules, capacity assignments) are swapped at deployment time using parameter rules rather than manual edits. Fabric deployment pipelines handle lakehouses, notebooks, and data pipelines with the same promotion pattern. Refresh schedules, gateway assignments, and alerting are applied through the Power BI REST API so they survive redeployment. A written change-management checklist covers dataset certification, dependency impact analysis, and rollback procedure for every promotion to production.

Which industries and data sources do you support most often?

Heaviest experience sits in healthcare, financial services, energy, manufacturing, and public sector, because each of those verticals pushes a different dimension of Power BI: HIPAA-bound PHI handling, transaction-grain reconciliation, time-series sensor data, cost-center-driven manufacturing variance, and FedRAMP-aligned government reporting. Source systems frequently include Microsoft Dynamics 365, SAP ECC and S/4HANA, Salesforce, Workday, Epic and Cerner (Oracle Health), Infor, and a long tail of legacy ODBC databases connected through on-premises data gateways. Fabric engagements add Azure Data Lake Storage, Snowflake, Databricks, BigQuery, and Amazon S3 through OneLake shortcuts. Regardless of source, the modeling discipline is identical: conformed dimensions, documented grains, and a semantic layer that hides the join complexity from report authors.

Fabric Real-Time Intelligence + Eventhouse Complete

Q: What is Fabric Real-Time Intelligence?

Fabric Real-Time Intelligence (RTI) is Microsoft Fabric's streaming analytics workload — real-time event ingestion, KQL analytics, and Power BI visualization on a single Fabric F-SKU capacity. RTI includes four components: Eventstream (declarative ingestion pipelines), Eventhouse (KQL-backed columnar store evolved from Azure Data Explorer), KQL Database (queryable interface), and Real-Time Dashboards (native RTI visualizations optimized for streaming data). RTI competes with Kafka + ClickHouse + Grafana stacks at Microsoft-native pricing.

Microsoft Fabric Real-Time Intelligence (RTI) is Fabric's streaming analytics workload — real-time event ingestion, KQL analytics, and Power BI visualization on a single F-SKU capacity. Eventhouse is the underlying KQL-backed store, evolved from Azure Data Explorer. Together they replace the traditional Kafka + ClickHouse + Grafana stack that most enterprises stitch together for real-time analytics, at Microsoft-native pricing and with Copilot integration. This guide covers RTI architecture, Eventhouse KQL basics, common streaming patterns, and 6 production use cases with F-SKU cost projections.

What is Fabric Real-Time Intelligence?

Fabric RTI is a Fabric workload comprising four components:

Eventstream — declarative pipeline for ingesting streams (Kafka, Azure Event Hubs, Azure IoT Hub, Google Pub/Sub, MQTT, custom REST endpoints)
Eventhouse — KQL-backed columnar store optimized for time-series and high-cardinality queries; evolved from Azure Data Explorer (ADX)
KQL Database — the queryable interface exposing KQL, T-SQL (limited), and REST API surfaces
Real-Time Dashboards — native RTI visualizations optimized for streaming data; alternative to Power BI for real-time use cases

All four components bill against the same Fabric F-SKU CU pool as Power BI, Data Engineering, and Copilot.

When to Use RTI (vs Alternatives)

Use RTI when: - Data velocity > 1000 events/second sustained - Query latency requirement < 5 seconds against last 24 hours of data - Time-series or high-cardinality (100k+ distinct values) query patterns - Already committed to Fabric F-SKU capacity

Do NOT use RTI when: - Batch analytics fits (< 1000 events/second) — use Fabric Lakehouse instead - Sub-100ms latency required — use Azure Cosmos DB with Kafka - Requires SQL Server compatibility for legacy tools — use Fabric Data Warehouse instead

Eventhouse KQL Basics

KQL (Kusto Query Language) is Microsoft's proprietary query language optimized for streaming and time-series. Core syntax:

```kql // Basic filter and aggregation on last 1 hour Events | where Timestamp > ago(1h) | where EventType == "PageView" | summarize Count = count() by bin(Timestamp, 1m), CustomerId | render timechart ```

Key KQL operators every engineer should know:

`| where` — filter (like SQL WHERE)
`| summarize` — aggregate (like SQL GROUP BY)
`| project` — select columns (like SQL SELECT)
`| join` — join two tables (kind=inner|leftouter|rightouter)
`| bin(column, interval)` — bucket by time interval
`| ago(1h)` — relative time literal
`| render` — inline visualization (barchart, timechart, piechart)

Advanced patterns:

`| make-series` — build sparse time series with fill-forward
`| series_decompose` — extract seasonality and trend
`| autocluster` — automatic anomaly clustering
`| take` — sample (like SQL LIMIT)

6 Production RTI Use Cases with F-SKU Cost Projections

Use case 1: Web analytics real-time dashboard

Volume: 500 events/second sustained, 5,000 events/second peak
Retention: 30 days hot, 6 months cool
Query pattern: Real-time dashboard refreshing every 30s, ad-hoc analyst queries
F-SKU cost impact: ~10 CU-seconds/second average = 10% of F64 capacity
Recommended: F64 with RTI as one workload alongside Power BI

Use case 2: Manufacturing OEE real-time monitoring

Volume: 200 events/second from 500 PLCs, mostly telemetry
Retention: 90 days hot for troubleshooting, 3 years cool for compliance
Query pattern: Fixed dashboards refreshing every 5s, alerting on threshold breaches
F-SKU cost impact: ~5 CU-seconds/second = 5% of F64 capacity
Recommended: F64 with RTI + Copilot for anomaly narration

Use case 3: Cybersecurity SIEM event analysis

Volume: 20,000 events/second (Windows events, network flow, endpoint telemetry)
Retention: 90 days hot, 1 year cool (compliance)
Query pattern: Threat hunting ad-hoc KQL queries, dashboards refreshing every 60s
F-SKU cost impact: ~120 CU-seconds/second = 187% of F64, need F128
Recommended: F128 with RTI + Fabric Data Science for detection models

Use case 4: Financial trading tick data

Volume: 50,000 events/second market data
Retention: 30 days hot for trader analytics
Query pattern: Sub-second dashboard refresh, high-cardinality queries by symbol
F-SKU cost impact: ~300 CU-seconds/second = requires F256+
Recommended: F256 with RTI on isolated capacity; Power BI on separate F-SKU

Use case 5: IoT smart building analytics

Volume: 800 events/second across 20,000 sensors
Retention: 1 year hot for facilities analytics
Query pattern: Facility manager dashboards, ML-driven predictive maintenance
F-SKU cost impact: ~15 CU-seconds/second = 23% of F64
Recommended: F64 with RTI + Fabric Data Science; Copilot for facility Q&A

Use case 6: Application performance monitoring

Volume: 3,000 events/second application metrics from 200 services
Retention: 60 days hot for incident investigation
Query pattern: SRE dashboards, alerting on latency percentiles
F-SKU cost impact: ~25 CU-seconds/second = 39% of F64
Recommended: F64 with RTI as primary workload

RTI Architecture Best Practices

Partition Eventhouse tables by ingestion date

Every high-volume table should partition by `ingest_time` at daily or hourly granularity. Enables partition pruning on time-scoped queries (the vast majority).

Use materialized views for common aggregations

Materialized views in Eventhouse pre-compute summaries on ingest. A dashboard showing "count by minute for last 24h" against a base 20k eps table should hit a materialized view, not the base table. Typical impact: 10-100x query speedup.

Set explicit retention and caching policy per table

Eventhouse defaults to indefinite retention. Every production table should have: - `retention policy softdelete = 30d` (or your requirement) - `caching policy hot = 7d` (frequently-queried window in hot cache)

Route RTI to isolated Fabric capacity for volume workloads

For high-velocity workloads (SIEM, trading, IoT at scale), route RTI to a dedicated F-SKU capacity separate from Power BI. Prevents streaming ingestion spikes from starving BI query CU.

Publish RTI real-time dashboards separately from Power BI dashboards

RTI native real-time dashboards render faster than Power BI dashboards for sub-second refresh use cases (SIEM, trading). Use Power BI for analytical historical exploration, RTI dashboards for real-time operational.

Related Guides

Ready to architect Fabric Real-Time Intelligence for your streaming workload? Book a 30-minute RTI assessment and we will size your capacity against your specific event volume and query pattern.