Stark Informatics
Home · Solutions · Eventhouse

Eventhouse

The streaming and time-series workspace in Microsoft Fabric. Holds one or more KQL databases optimized for billions of events, IoT telemetry, logs, and append-only feeds — with sub-second query latency.

GAWorkload · Real-Time Intelligence· 8 min read

What it is

An Eventhouse is the Fabric item that groups one or more KQL databases. Think of it as the Real-Time Intelligence equivalent of a server — KQL databases are the databases on it. It manages shared compute, caching, and policies across its KQL databases.

Under the hood, it's the same Azure Data Explorer engine that powers Azure Monitor, Microsoft Sentinel, and Application Insights. The engine specializes in append-mostly, time-series, and high-cardinality workloads — the patterns that traditional warehouses struggle with.

When to use it

Default to an Eventhouse when:

  • Your data is event-shaped: telemetry, IoT readings, application logs, clickstreams, security events.
  • You need sub-second queries over billions of rows.
  • Your data is append-only or rarely updated.
  • Time-series operators (bin, summarize, anomaly detection, forecasting) are common in queries.
  • Schema is semi-structured (JSON payloads).

Prefer a Lakehouse or Warehouse for batch analytics over structured, conformed data where queries take minutes (not seconds).

How it fits in Fabric

Eventhouses pair naturally with Eventstreams (for ingestion), Real-Time Dashboards (for visualization), and Activator (for alerts). They also serve Data Agents directly — KQL databases are a first-class data source for conversational analytics over telemetry data.

OneLake availability

By default, Eventhouse data is stored in the engine's optimized column store. Turn on OneLake availability to mirror the same data into OneLake as Delta-Parquet — readable by Lakehouse SQL endpoints, Spark notebooks, Power BI Direct Lake, and external engines. No copies, no duplication, just an additional read surface.

i
Net effect: Operations teams query in KQL for sub-second drill-down. Analysts query the same data in T-SQL or DAX through OneLake. One copy of data, two access patterns.

Best practices

  • One Eventhouse per workload domain. Telemetry, security, and product analytics each get their own.
  • Use update policies for incremental transformation. Materialize derived tables as data arrives.
  • Define caching policies aligned to query patterns. Hot cache for the last 7 days; cold storage for the rest.
  • Set retention policies aggressively. Most operational telemetry is uninteresting after 90 days.

Common pitfalls

!
Using Eventhouse for OLTP-style workloads. Eventhouse is append-optimized. Frequent updates and deletes will hurt.
!
Forgetting to enable OneLake availability. Without it, analysts who don't know KQL are locked out.

Designing a real-time analytics platform?

Our Real-Time Anomaly Detection accelerator gets you from event source to Teams alert in days.

See the accelerator