Episodes

  • ML Models in Fabric: Training, Deployment, and When to Stay on Azure ML

    ML Models in Fabric: Training, Deployment, and When to Stay on Azure ML
    May 29 2026
    ML Models in Fabric: Training, Deployment, and When to Stay on Azure ML Episode 22 • 2026-05-29 Microsoft Fabric ships its own MLflow registry — but is it a replacement for Azure Machine Learning? Matthias and Fabia work through the four-layer registry model, PREDICT versus Model Endpoints, the Direct Lake prediction loop, and the architectural question that actually determines the answer: where do your predictions land? What we discuss A 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 home Key takeaways Where do the predictions land. That question answers the architecture. OneLake plus Power BI Direct Lake — Fabric ML Model, genuinely the right call. REST API for an app — evaluate Endpoints maturity or route to Azure ML. GPU training,...I'd go further. Already on Databricks with Unity Catalog? Don't migrate. Fabric ML Model is not a migration target for Databricks shops — the platform maturity gap is real. The hybrid that actually works: train on Azure ML with GPU,...For Power BI shops — yes. PREDICT writes predictions to a Delta table in OneLake, Direct Lake reads it with zero copy, zero scheduled refresh. That eliminates an entire class of ETL work. But only if Power BI is your audience. Resources ML ExperimentNotebooksLakehouseDirect LakeCode-first AutoMLLow-code AutoMLSynapseMLActivatorMachine learning model in Microsoft FabricWhat is Data Science in Microsoft Fabric?Tutorial Part 3: Train and register a machine learning modelTutorial Part 4: Perform batch scoring and save predictionsMachine learning model scoring with PREDICTServe real-time predictions with ML model endpoints (Preview)Train models with scikit-learn in Microsoft Fabric About the show Built 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 case Have 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.
    Show More Show Less
    10 mins
  • Event Schema Set: Contracts That Stop Midnight Breakage

    Event Schema Set: Contracts That Stop Midnight Breakage
    May 22 2026
    Event Schema Set: Contracts That Stop Midnight Breakage Episode 21 • 2026-05-22 Event Schema Set is Fabric's contract layer for streaming data — but it ships in Preview with real gaps. Matthias and Fabia unpack the retrofit trap, the dead-letter gap everyone worries about, and when Confluent Schema Registry is honestly the better call. What we discuss A 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 home Key takeaways Treat schemas as append-only contracts. Add fields with defaults — safe. Remove required fields — breaks consumers. Change a type — silent data corruption. Rename a field — silent loss in KQL queries. The system won't stop you. Your...Fair argument. And honestly? If you're an existing Kafka shop with established Confluent practices — use Confluent. The migration cost isn't worth it. Eventstream can deserialize Confluent-encoded payloads natively. You get Avro plus JSON...But you operate a separate cluster. Separate auth. Separate billing. If your entire stack is Fabric-native — Eventstream, Notebook, Activator, Eventhouse — the integration is a real win. No client library. No external cluster. Governance... Resources Schema Registry — known limitationsCloudEvents 1.0Use schemas in eventstreamsReal-Time Hub SchemasBusiness Events ConceptsConsume Business Events from ActivatorEventhouseConfluent Kafka sourceSchema Registry in Fabric Real-Time Intelligence (preview) — OverviewCreate and manage event schema setsCreate and manage event schemas in schema setsEventSchemaSet REST API definitionEventstream Overview — Schema Management sectionMultiple-Schema Inferencing in Eventstream (Preview)Eventstream Data Formats: JSON, CSV, Avro About the show Built 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 case Have 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.
    Show More Show Less
    11 mins
  • Data Activator: Stateful Alerts That Don't Spam Your Team

    Data Activator: Stateful Alerts That Don't Spam Your Team
    May 15 2026
    Data Activator: Stateful Alerts That Don't Spam Your Team Episode 20 • 2026-05-15 Data Activator is Fabric's no-code event detection engine — but most teams build it wrong. Matthias and Fabia unpack the stateful rule model, the billing trap everyone hits once, and when Power Automate is actually the better answer. What we discuss A 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 home Key takeaways Take-home: the entity hierarchy is the product.Fair. For low-frequency data — a daily KPI check — it works fine. Where it breaks: ten thousand events per second per rule. Power Automate isn't built for that volume. And a per-flow variable isn't per-object state — you'd need one flow...Right. Wrong in exactly one place — the state machine. Here's the thing. A stateless rule fires on every matching event. Value greater than twenty-five? Sensor reports every five seconds, stays above twenty-five for an hour — you get seven... Resources Add Activator to EventstreamActivator from KQL QuerysetActivator from RTDActivator from Power BIReal-Time Hub Set AlertsSet Alerts on Anomaly DetectionWhat is Fabric Activator?Tutorial: Create and activate a Fabric Activator ruleCreate a rule in Fabric ActivatorTrigger modeling in ActivatorFabric Activator rulesDetection conditionsActivator LimitationsLatency in ActivatorActivator Capacity Consumption About the show Built 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 case Have 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.
    Show More Show Less
    9 mins
  • Real-Time Dashboard: When 10-Second Refresh Changes the Architecture

    Real-Time Dashboard: When 10-Second Refresh Changes the Architecture
    May 8 2026
    Real-Time Dashboard: When 10-Second Refresh Changes the Architecture Episode 19 • 2026-05-08 Real-Time Dashboard is not Power BI wearing a different hat. Matthias and Fabia unpack the naming collision, permission separation, Activator alert traps, and when you should actually use Power BI DirectQuery instead. What we discuss A 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 home Key takeaways If someone asks 'what's happening right now' — Real-Time Dashboard.But you lose permission separation. You lose tile-as-query simplicity. And your team will absolutely blame the network when the DirectQuery report takes four seconds to load at scale. Different tools, different tradeoffs.Fair argument. Power BI can connect to KQL via DirectQuery. You get DAX measures, RLS, the full semantic model. And in Premium, automatic page refresh goes as low as five seconds. So if your team already lives in Power BI — that's a legitimate path. Resources KQL DatabaseKQL QuerysetReal-Time HubActivator on RTDAnomaly DetectionPower BI + KQLFabric MapWhat is Real-Time Dashboard?Create a Real-Time DashboardReal-Time Dashboard PermissionsUse Parameters in Real-Time DashboardsCustomize Real-Time Dashboard VisualsActivator LimitationsGenerate Real-Time Dashboard with CopilotCopilot-assisted Real-Time Data Exploration (Preview) About the show Built 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 case Have 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.
    Show More Show Less
    9 mins
  • Real-Time Hub: The Yellow Pages Your Streams Were Missing

    Real-Time Hub: The Yellow Pages Your Streams Were Missing
    May 4 2026
    Real-Time Hub: The Yellow Pages Your Streams Were Missing Episode 18 • 2026-05-01 Matthias and Fabia unpack Fabric's Real-Time Hub — the tenant-wide catalog that sits above Eventstream, Eventhouse, and Activator. They tackle why it feels redundant until it doesn't, dig into a real Reddit question about skipping the Hub entirely, and lay out the four-layer real-time stack every architect should internalize. What we discuss A 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 home Key takeaways So — today's lesson. The Hub is not a processing engine. It's not a new Eventstream. It's the inventory layer that streaming has always been missing. Pattern dictates platform — if your pattern is discovery at organizational scale, this is...I mean, fair question. If every stream you have lives in one workspace and one team owns them all — the Hub's discoverability value is close to zero. You already know what exists. Same if you're publishing streams to non-Fabric consumers...Right. And... that's actually fine for small setups. The connector list is identical — same Azure Event Hubs tile, same Kafka tile, same CDC tiles. Both paths end up creating an eventstream artifact. But here's the thing. Eventstream is... Resources managed private endpointEventstream OverviewKQL DatabaseActivator OverviewReal-Time DashboardSchema SetsDigital Twin BuilderReal-Time Hub OverviewGet Started with Real-Time HubSupported SourcesAdd Azure Event Hubs SourceAdd Azure IoT Hub SourceGet Azure Blob Storage EventsCreate Streams from Workspace Item EventsCreate Streams from OneLake Events About the show Built 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 case Have 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.
    Show More Show Less
    11 mins
  • KQL Queryset: Why Pipe-Forward Beats SQL for Time-Series

    KQL Queryset: Why Pipe-Forward Beats SQL for Time-Series
    May 1 2026
    KQL Queryset: Why Pipe-Forward Beats SQL for Time-SeriesEpisode 17 • 2026-04-24 Duration: 9:39Matthias and Fabia explore the KQL Queryset in Microsoft Fabric — why the pipe-forward mental model beats SQL for time-series data, when to use make-series vs bin+summarize, and the architectural decision between KQL Queryset, Notebooks, and the SQL endpoint.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 takeawaysSo — the lesson. Show me the query pattern. That's it. Don't pick your tool based on what you know. Pick it based on what the data needs. If you're doing time-series at scale, learn the pipe. It's worth it.I mean, fair question. If your workload is analytical reporting — quarterly trends, executive dashboards, scheduled refresh — Power BI connected through the SQL endpoint is probably the better path. You get a richer visualization library,...Right. And the naive answer is — just use the T-SQL endpoint, it supports SELECT statements. Which is true. But here's the thing. T-SQL on a KQL database is read-only DQL. SELECT only. No DDL, no management commands. And more importantly —...ResourcesQuery data in a KQL querysetCreate a KQL querysetKusto Query Language overviewSQL to KQL cheat sheetKQL quick referencemake-series operatorseries_decompose_anomalies()Anomaly detection and forecastingTime series analysisrender operatorShare KQL queriesCreate a Real-Time DashboardReal-Time Intelligence tutorial part 5: Query streaming data using KQLTutorial: Learn common operatorsTutorial: Use aggregation functionsAbout 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.
    Show More Show Less
    10 mins
  • KQL Database: Why Time-Series Data Needs Its Own Engine

    KQL Database: Why Time-Series Data Needs Its Own Engine
    May 1 2026
    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.
    Show More Show Less
    10 mins
  • Eventstreams — When No-Code Streaming Hides the Failure Mode

    Eventstreams — When No-Code Streaming Hides the Failure Mode
    Apr 10 2026
    Eventstreams — When No-Code Streaming Hides the Failure Mode Episode 15 • 2026-04-10 Duration: 8:03 Matthias and Fabia break down Fabric Eventstreams — the visual stream processor that replaces three Azure services with one canvas. They explore why green doesn't always mean flowing, tackle Kafka compatibility from a real Reddit question, and walk through the four billing meters that confuse every FinOps team. What we discuss A 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 home Key takeaways Eventstreams are not about replacing Spark or Kafka.Fair. If you need stateful ML inference mid-stream, Eventstreams won't do it — route to a Spark Notebook destination instead. And if your team needs exactly-once semantics, at-least-once with deduplication in Eventhouse covers most cases,...And your team will absolutely say that in the sprint demo. Resources Eventstream OverviewAdd and manage event sourcesRoute events to destinationsEdit and publish an eventstreamRoute data streams based on contentDeltaFlow output transformationMonitor the status and performance of an eventstreamPause and resume data streamsCapacity consumption for Fabric eventstreamsAdd Azure Event Hubs sourceAdd Azure IoT Hub sourceAdd Eventhouse destinationAdd Lakehouse destinationProcess events with SQL code editorExplore and transform bike-sharing data About the show Built 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 case Have 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.
    Show More Show Less
    8 mins