KQL Database

What it is

A KQL Database lives inside an Eventhouse and stores append-mostly data. It excels at high-cardinality, time-stamped, and semi-structured data — telemetry, logs, clickstreams, IoT readings, security events. Behind the scenes it's the same engine that runs Azure Data Explorer; in Fabric it's just one more item in a workspace.

Why KQL

Kusto Query Language is purpose-built for time-series. A typical query reads naturally:

SensorReadings
| where timestamp > ago(1h)
| where reading > 90
| summarize count() by bin(timestamp, 1m), sensor_id
| render timechart

Once you've written 50 lines of KQL you'll be faster than the equivalent SQL — and the engine is purpose-tuned for the shape of these queries.

Built-in features

• Materialized views for pre-aggregated lookups.
• Update policies to transform data as it arrives (the streaming-ETL pattern).
• Time-series and anomaly functions: series_decompose_anomalies, series_outliers.
• Inline ML: clustering, decision trees, forecasting.
• JSON / dynamic columns with first-class operators (extend, mv-expand).
• OneLake availability — toggle a switch and the data is also Delta-Parquet in OneLake.

Common patterns

• Bronze → Silver: raw events into a Bronze table; update policy projects into a typed Silver table.
• Pre-aggregated KPIs: materialized view that's always fresh; dashboards query it.
• Sliding-window anomaly detection: series_decompose_anomalies over a binned time series, triggering an Activator alert.

Best practices

• Choose your partitioning carefully. Default works for most; high-cardinality tenants need an explicit partition key.
• Set retention policies. Without them, data accumulates indefinitely.
• Use functions to encapsulate query logic. Like stored procedures, but inlineable.
• For long queries, store and version them as functions in source control.

Common pitfalls

Related items