Eventhouse and KQL Databases: Real-Time Intelligence in Microsoft Fabric

What Is an Eventhouse?#

An Eventhouse is a workspace-level container in Microsoft Fabric's Real-Time Intelligence workload, purpose-built for high-volume telemetry, event streams, and time-series data. It can host multiple KQL (Kusto Query Language) databases, and those databases share the Eventhouse's underlying capacity and resources rather than each provisioning their own ^[S1]. Real-Time Intelligence storage is hierarchical: a workspace can contain multiple Eventhouses, an Eventhouse can contain multiple KQL databases, and each KQL database can contain multiple tables ^[S2].

That shared-capacity design is the first thing to understand about Eventhouse economics: cost and performance are jointly optimized across every database inside the container, not tuned in isolation per database ^[S1]. If you're used to provisioning a database server per workload, this is a different mental model — you provision an Eventhouse, then place related databases inside it to share the pool.

Eventhouses automatically organize ingested records by arrival time, which is what makes fast, indexed queries possible over structured, semi-structured, and unstructured data at any scale. Data landing in an Eventhouse is also mirrored to OneLake as a single logical copy, so it becomes reachable by other Fabric experiences without a separate export step ^[S3].

Core Concepts#

Two Query Surfaces, One Dataset#

Every Eventhouse database is queryable two ways: through native KQL, and through a T-SQL analytics endpoint that Fabric manages and governs on your behalf. KQL querysets can also be queried through T-SQL where that applies ^[S3]. This dual-surface design exists to widen adoption — BI tools and SQL-literate analysts can connect without learning KQL's pipe-based syntax, while engineers who do know KQL get the language's full expressiveness for time-series analytics ^[S3].

Native Anomaly Detection#

Eventhouse includes anomaly detection that evaluates live time-series and event data in place — no data copies, no export step ^[S3]. Because detection runs against the live dataset rather than a downstream replica, it reduces detection latency and lets an analyst pivot straight from a dashboard alert into a live KQL query on the same data ^[S3].

Eventhouse includes native anomaly detection that evaluates live time-series and event datasets in place, without requiring data copies or exports.

Shortcuts Are External Tables, Not Copies#

A shortcut created inside a KQL database lands in that database's Shortcuts folder and behaves as an external table — you query it with Kusto's external_table() function rather than referencing it like a native table ^[S4]. This is how a KQL database reaches data already sitting in OneLake or another supported source without ingesting a copy.

AnomalyEvents
| union external_table('raw_telemetry_shortcut')
| where Timestamp > ago(1h)
| summarize count() by bin(Timestamp, 5m)

OneLake as a Peer, Not a Downstream Export#

OneLake availability can be switched on for a KQL database at the database level — covering all current and future tables, with an optional backfill of existing data — or at the individual table level for finer-grained control ^[S1]. Once enabled, the table's data is exposed in Delta Lake format and becomes directly queryable by Power BI Direct Lake mode, Warehouse, Lakehouse, and Spark notebooks with no data movement or copy step, and at no additional storage charge beyond the standard OneLake tier already billed ^[S1].

The KQL retention policy governs the OneLake copy in lockstep: when data ages out of the KQL database, it is concurrently soft-deleted from OneLake ^[S1]. One lifecycle policy controls both places the data lives — there is no second retention clock to manage.

How It Works: Best Practices#

Scope OneLake availability to what downstream engines actually need#

Enable OneLake availability at the table level rather than the database level when only some tables should be visible to Spark, Warehouse, or Direct Lake consumers — database-level enablement exposes every current and future table in one action ^[S1].

// Wrong: database-level enablement exposes every table,
// including ones with unreviewed sensitive columns
{ "scope": "database", "target": "raw_telemetry" }

// Right: enable per table, only for the aggregate consumers
// that actually need it
{ "scope": "table", "target": "aggregated_metrics" }
{ "scope": "table", "target": "anomaly_events" }

Finish schema and RLS work before enabling OneLake availability#

While OneLake availability is active on a table, several DDL operations are blocked outright: renaming the table, changing a column's data type, applying row-level security, and deleting or purging rows ^[S1]. You must disable OneLake availability to run any of them — and re-enabling it afterward triggers a full historic backfill, which is expensive on a large table ^[S1].

Share at the right level#

Sharing an Eventhouse link propagates the sender's permission level across every child item — KQL databases, tables, dashboards, functions, materialized views, and embedded querysets. Sharing an individual KQL database, by contrast, grants access only to that database and excludes Eventhouse-level navigation such as the system overview or the database list ^[S1].

# Wrong: vendor team only needs read access to raw_telemetry,
# but gets shared the whole Eventhouse for convenience
Share: Eventhouse FleetAnalytics -> vendor-team@contoso.com
# Result: vendor team can now see every database, dashboard,
# and function in the Eventhouse

# Right: share the specific database only
Share: KQLDatabase FleetAnalytics/raw_telemetry -> vendor-team@contoso.com

Design for cold-start latency#

An Eventhouse compute node becomes available within 5 to 10 seconds of a cold start, because the engine is fully managed and autoscales ^[S1]. For pipelines that may sit idle and then need to respond immediately, that warm-up window is a real latency component to budget for, not just theoretical fine print.

What Goes Wrong#

Small files pile up when mirroring latency is set too low#

When OneLake availability is on, an adaptive batching mechanism delays writes to OneLake until enough data has accumulated to produce optimally sized Parquet files, typically 200–256 MB. The default maximum delay is up to 3 hours, and the mirroring policy can lower that to as little as 5 minutes — but smaller delays risk producing many small files, which degrades query performance for downstream consumers ^[S1].

Rule of thumb: leave the mirroring delay at its default unless a specific downstream consumer needs fresher OneLake data and can absorb the small-file trade-off.

Throttling escalates in three stages, and the last one can lose data#

When query demand exceeds available capacity, an Eventhouse throttles in three escalating stages ^[S1]:

Only the extreme-reactive stage risks losing events, and only after a holding period — but it exists, which means workloads with a zero-loss requirement need to monitor CU consumption and configure surge protection before capacity pressure gets that far ^[S1].

Internals#

Architecture & design#

An Eventhouse is the top-level container: it owns the shared capacity pool, and everything below it — KQL databases, and the tables inside them — draws from that pool ^[S1]. Monitoring reflects this hierarchy directly. A single system-overview page at the Eventhouse level tracks storage, compute, ingestion rates, and top-queried databases across every KQL database it contains, while each individual KQL database exposes its own narrower set of metrics ^[S1].

Access control follows the same container-vs-item split. An Eventhouse-level share grants visibility into everything inside it — databases, tables, dashboards, functions, materialized views, querysets — while a database-level share is scoped to that one database and hides Eventhouse-level navigation entirely ^[S1]. Architecturally, this means the Eventhouse is both a billing boundary and a security boundary, and the two line up: whoever administers the shared capacity pool is naturally also the one positioned to grant the broad share.

OneLake sits alongside this structure as a peer storage layer rather than a downstream copy target. Because the OneLake Delta representation is generated directly from the KQL engine's own data and governed by the same retention policy, it behaves architecturally like a second query surface on the same data rather than a replicated pipeline with its own lifecycle ^[S1].

How it works internally#

Storage inside a KQL database is split into two independently billed tiers ^[S1]:

• A premium cache tier — comparable to ADLS premium storage — that holds the hot dataset. What lives here is controlled by the caching policy.
• A standard tier — comparable to ADLS hot storage — that holds the full retention window. What lives here is controlled by the retention policy.

Data outside the cache window is not gone — it is still queryable from the standard tier, just at higher latency, because the retention policy's window is a superset of the caching policy's window. Shortening the cache window reduces premium-tier spend without shrinking the total queryable history ^[S1]. This is the mechanism that lets you decouple how far back you can query fast from how far back is required for compliance.

The OneLake write path runs on an adaptive batching algorithm: rather than flushing on a fixed timer, the engine accumulates data until it can assemble a Parquet file in the 200–256 MB range, and only then writes it to OneLake ^[S1]. The delay this produces is bounded — 3 hours by default, configurable down to 5 minutes through the mirroring policy — but the batching itself is throughput-driven, not clock-driven: high-ingestion periods hit the size target quickly and flush often, while low-ingestion periods wait longer for enough data to accumulate ^[S1].

Performance characteristics#

Capacity consumption for an Eventhouse is metered through an UpTime metric: CU seconds consumed equal the number of active seconds multiplied by the virtual core count the autoscaler has allocated to that Eventhouse. When a KQL database is a child item of an Eventhouse — the standard configuration — its UpTime rolls up to the Eventhouse item, and no separate CU line appears for the database sub-item ^[S1]. In practice this means capacity metrics report Eventhouse-level totals; attributing cost to one specific database inside a shared Eventhouse requires estimating from per-database monitoring metrics rather than reading it directly off a CU line. Inference: teams with a hard chargeback requirement per database should consider a dedicated Eventhouse per cost center instead of relying on the shared pool.

The throttling ladder is itself a performance characteristic worth planning around: proactive throttling slows queries while leaving ingestion untouched, reactive throttling pauses both without losing data, and only extreme-reactive throttling — reached after a holding period — introduces data-loss risk ^[S1]. The staged design means the system sheds query load before it ever touches ingestion, which is the right order of priorities for a telemetry-capture workload where losing the write path is worse than a slow dashboard.

Cold-start behavior is also a measured characteristic, not a documented SLA promise: a compute node becomes available within 5 to 10 seconds of a cold start because the engine is fully managed and autoscales ^[S1]. That is a small number in absolute terms, but it is nonzero, and it is the number to budget against for any pipeline where the Eventhouse may go idle between bursts.

Worked Example: Fleet Telemetry Eventhouse#

A fleet management team ingests GPS, engine metrics, and diagnostic codes from thousands of vehicles into a single Eventhouse in the "FleetAnalytics" workspace.

Layout — one Eventhouse, three KQL databases sharing its capacity pool ^[S1]:

Eventhouse: FleetAnalytics
├── KQLDatabase: raw_telemetry        (ingest-only, high volume)
├── KQLDatabase: aggregated_metrics   (rollups for dashboards)
└── KQLDatabase: anomaly_events       (alerting)

Storage policy on raw_telemetry — cache window set to 3 days (the live-ops query window), retention set to 180 days for compliance, so recent data is fast and older data is still queryable, just slower ^[S1]:

.alter-merge table RawTelemetry policy caching hot = 3d
.alter-merge table RawTelemetry policy retention softdelete = 180d

OneLake exposure, scoped deliberately — the aggregated table is exposed for Power BI Direct Lake; the raw table is not, because it carries unreviewed diagnostic codes:

{ "scope": "table", "target": "aggregated_metrics", "onelake_availability": true }
{ "scope": "table", "target": "raw_telemetry", "onelake_availability": false }

Query paths:

• The operations dashboard hits aggregated_metrics through the T-SQL analytics endpoint, so the Power BI team never has to write KQL ^[S3].
• The alerting system runs native KQL anomaly detection directly against raw_telemetry in place, catching engine-temperature deviations without exporting data to a separate store ^[S3].
• A data-science notebook reaches raw_telemetry through a Lakehouse shortcut, querying it in KQL with external_table('raw_telemetry_shortcut') ^[S4].

Capacity governance — surge protection caps the FleetAnalytics workspace at a fixed share of total tenant CU over a rolling 24-hour window, leaving headroom for other workspaces on the same capacity; FleetAnalytics is not marked mission-critical, so it is throttled like any other workspace if it breaches the cap ^[S1].

Inference: this three-database layout is a common pattern for exactly this reason — it separates raw capture, processed aggregates, and alerting into governance-appropriate units (different OneLake exposure, different retention) while still sharing one CU pool, so splitting responsibilities doesn't multiply cost.