KQL Database: Why Time-Series Data Needs Its Own Engine episode artwork

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.

Episode metadata supplied by the publisher feed · Published May 1, 2026

Embed this episode

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.

Distinct summary based on available episode metadata or transcript content.

NOW PLAYING

KQL Database: Why Time-Series Data Needs Its Own Engine

0:00 10:27

No transcript for this episode yet

We transcribe on demand. Request one and we'll notify you when it's ready — usually under 10 minutes.

No similar episodes found.

No similar podcasts found.

Frequently Asked Questions

How long is this episode of Fabric Architecture Podcast?

This episode is 10 minutes long.

When was this Fabric Architecture Podcast episode published?

This episode was published on May 1, 2026.

Is there a transcript available for this episode?

Yes, a full transcript is available for this episode. You can read the complete transcript on the episode page.

Can I download this Fabric Architecture Podcast episode?

Yes. Use the download control on the episode player to save the publisher-provided media file.
URL copied to clipboard!