In Short: The Third Engine, for the Third Kind of Data
Fabric's lakehouse and warehouse cover batch analytics well, but a third class of data breaks them at scale: telemetry. Logs, events, IoT readings, clickstreams - billions of small, time-stamped rows arriving continuously, queried by time window and dimension, expected to answer in seconds. Eventhouse is Fabric's purpose-built home for that class: KQL databases on the Kusto engine, the same technology behind Azure Data Explorer and Azure Monitor.
If your teams have ever tried to serve operational logs from a SQL warehouse, you already know why this engine exists.
What Makes the Engine Different
Kusto's design assumptions match telemetry, not transactions: data is append-mostly, freshness matters, and queries slice time ranges across huge row counts. Ingestion is continuous and near real time from eventstreams and direct connections; storage is columnar, compressed and aggressively indexed for time and text; and queries return interactively over volumes that would make a row-store weep.
The query language, KQL, is half the appeal. Pipe-based and readable top to bottom, it makes exploratory questions - filter to yesterday, summarise by device, chart the trend - feel like a conversation rather than a subquery puzzle. SQL-skilled analysts pick it up in days, and native time-series functions (including the anomaly detection that powers real-time alerting) come built in.
Where It Sits in the Fabric Picture
An Eventhouse hosts one or more KQL databases and plugs into the rest of the platform.
- In: eventstreams route events from IoT hubs, Kafka-style sources and applications; historical loads arrive from files and pipelines
- Out: real-time dashboards for live operations views; Activator rules that act on conditions; and OneLake availability, which exposes KQL data as Delta for Spark, SQL and semantic models
- Across: shortcuts work in both directions, so the event estate and the batch estate reference rather than copy each other
Billing is ordinary capacity consumption, with the caveat that always-on ingestion has a steadier profile than batch: size for the floor, not just the peaks.
The Decision Rule: Eventhouse or Lakehouse?
Ask three questions of the workload.
Shape: time-stamped, append-heavy, high-cardinality? Eventhouse territory. Business entities heading for a star schema? Lakehouse and warehouse.
Latency: do users need data seconds after it happens, filtered and aggregated on demand? Kusto. Is daily or hourly fine? Batch layers are cheaper to operate.
Query style: exploratory slicing over time windows and text (investigations, monitoring, funnels)? KQL shines. Fixed dimensional reporting? Semantic models over gold.
Most estates that adopt Eventhouse keep both: telemetry lands in KQL for operations and investigation, distilled aggregates flow to gold for executive reporting, and each engine does the job it was built for. The mistake is forcing one engine to be all three - which is precisely the architecture Fabric was designed to end.
Sources and Further Reading
Frequently asked
The Real-Time Intelligence workload's storage item: a home for one or more KQL databases, built on the Kusto engine that powers Azure Data Explorer. It is optimised for high-volume, time-stamped data - logs, events, telemetry - ingested continuously and queried at interactive speed.
Kusto Query Language: a pipe-based query language designed for exploring time-series and log data. SQL-skilled analysts typically become productive in days - queries read top to bottom through operators like where, summarize and render - and the exploratory feel is genuinely pleasant for telemetry work.
When it is high-volume, append-heavy and time-stamped, and users need fresh, fast, filtered queries: operational logs, IoT sensor streams, clickstream, application events. Business transactions heading for star schemas stay in lakehouses and warehouses; the two coexist in most real estates.
Yes: KQL databases can make their data available in OneLake, so Spark, SQL and semantic models can reach it, and shortcuts work in both directions. Real-time dashboards and Activator consume it natively.
It brings the same engine into Fabric's SaaS model, capacity billing and governance. Organisations already running ADX will find the concepts identical; new estates simply get Kusto without managing a cluster.
