What an Eventhouse actually is#
An Eventhouse is a workspace-level container built to hold high-volume, time-stamped data — telemetry, logs, or sensor readings arriving continuously rather than in scheduled batches. The storage hierarchy nests three levels deep: a workspace can hold multiple eventhouses, each eventhouse can hold multiple KQL databases, and each KQL database can hold multiple tables [S1]. "KQL" is short for Kusto Query Language, the query language these databases use.
The container level is a real sharing boundary, not just a folder. Databases in the same Eventhouse jointly share its underlying capacity, so cost and performance are optimized across all of them together [S2]. Monitoring reflects this: a single system-overview page at the eventhouse level tracks storage, compute, ingestion, and top-queried databases, while each KQL database only exposes its own narrower metrics [S2].
Getting data in and out#
Eventhouses are built for ingest-then-query speed: records are automatically organized by arrival time as they land, keeping queries fast and indexed at large scale [S3]. That data isn't locked to KQL alone — every Eventhouse table is also mirrored to OneLake as a single logical copy, so other Fabric engines can read it without a separate export step [S3]. Querying has two front doors: native KQL for full expressiveness, and a T-SQL analytics endpoint plus KQL querysets for people and BI tools that prefer SQL [S3]. Data living outside the database can also be pulled in via a shortcut — it lands in the Shortcuts folder and is queried with external_table() rather than as a native table [S4].
A worked example#
A fleet-monitoring team creates one Eventhouse for all vehicle telemetry and puts three KQL databases inside it, one per business unit, so shared capacity absorbs uneven load instead of each database needing its own headroom [S2]. A data engineer building a medallion-style pipeline lands raw telemetry into a Bronze table inside that Eventhouse, either from an Eventstream destination or written straight into a raw table [S5]. An analyst who only knows SQL later connects a BI tool to the T-SQL analytics endpoint and queries the same data without writing any KQL [S3].
What goes wrong#
- Splitting related data across many eventhouses by default. Capacity and monitoring are shared at the eventhouse level, so scattering related databases across separate eventhouses forfeits that efficiency and hides fleet-wide health behind narrower per-database views [S2].
- Querying a shortcut like a native table. A shortcut lands as an external table and must be queried with
external_table(), not treated as directly ingested data [S4]. - Assuming Copilot works the same everywhere. Under Outbound Access Protection, Copilot-powered query generation for Eventhouse is not supported, though manually authored KQL queries continue to work unaffected [S6].