EPISODE · May 1, 2026 · 10 MIN
KQL Database: Why Time-Series Data Needs Its Own Engine
from Fabric Architecture Podcast · host Matthias Falland
KQL Database: Why Time-Series Data Needs Its Own EngineEpisode 16 • 2026-04-17 Duration: 10:26Matthias and Fabia explore why KQL Database exists alongside four other analytical stores in Microsoft Fabric. They unpack the Eventhouse-as-building mental model, the caching vs retention trap, and when you should — and shouldn't — choose KQL over SQL.What we discussA real-world mistake from a pre-Fabric eraThe one question that reframes the architectural debateHow we got here — predecessor products and evolutionWhy the "obvious" answer is often wrongA real Reddit/Microsoft Q&A question unpackedThe concrete recommended architectureF-SKU realism — what this actually costsWhen the rejected approach is actually rightRisks of the recommended pathWhat Microsoft is shipping that changes the calculusThe architectural principle to take homeKey takeawaysIf your data is time-series, logs, or telemetry — and your queries are always filtered by time — KQL Database isn't just an option.Fair. And honestly, if your team has strong Python skills and your latency tolerance is minutes, not milliseconds — Lakehouse plus notebooks is a legitimate path. You get the Spark ecosystem, ML libraries, broader tooling. I wouldn't fight...Right. And that matters for the reversal. Because the naive answer teams land on is: just put your IoT data in the Lakehouse. Delta Lake handles everything, right?ResourcesWhat is Real-Time Intelligence?Choose an analytical data store in Microsoft FabricEventhouse overviewData connectors overviewGet data overviewChange data policiesKQL overview - scalar data typesEventhouse and KQL Database consumptionPricing cost driversCreate a KQL databaseTime series analysisAnomaly detection and forecastingManage and monitor a databaseManage and monitor an eventhouseKQL Database git integrationAbout the showBuilt on ElevenLabs voice synthesis. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.Submit your caseHave an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.Built on ElevenLabs voice synthesis. Brand design based on fabricperiodictable.com.
Embed this episode
What this episode covers
Matthias and Fabia explore why KQL Database exists alongside four other analytical stores in Microsoft Fabric. They unpack the Eventhouse-as-building mental model, the caching vs retention trap, and when you should — and shouldn't — choose KQL over SQL.
NOW PLAYING
KQL Database: Why Time-Series Data Needs Its Own Engine
No transcript for this episode yet
Similar Episodes
No similar episodes found.
Similar Podcasts
No similar podcasts found.