Fabric Architecture Podcast

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 era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The 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 endpoint Eventstream Overview KQL Database Activator Overview Real-Time Dashboard Schema Sets Digital Twin Builder Real-Time Hub Overview Get Started with Real-Time Hub Supported Sources Add Azure Event Hubs Source Add Azure IoT Hub Source Get Azure Blob Storage Events Create Streams from Workspace Item Events Create 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.

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.

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.

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 era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The 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 Overview Add and manage event sources Route events to destinations Edit and publish an eventstream Route data streams based on content DeltaFlow output transformation Monitor the status and performance of an eventstream Pause and resume data streams Capacity consumption for Fabric eventstreams Add Azure Event Hubs source Add Azure IoT Hub source Add Eventhouse destination Add Lakehouse destination Process events with SQL code editor Explore 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.

Eventhouse — Why Your Lakehouse Can't Do Real-Time Episode 14 • 2026-04-03 Duration: 7:32 Matthias and Fabia break down Microsoft Fabric's Eventhouse — when you need a dedicated real-time store, how hot and cold cache tiers drive your bill, and why the default cache policy is the most common Eventhouse mistake. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path The architectural principle to take home Key takeaways Don't default your real-time data into the Lakehouse just because it's familiar. Completely. If your latency tolerance is five to thirty seconds and you already know Spark — that's a defensible architecture. Eventhouse costs you KQL ramp-up, a separate billing model, one more item to govern. Don't add an engine just... Right. Now — the naive answer when someone asks 'where do I put streaming data in Fabric' is always the Lakehouse. Everything goes to OneLake. Sounds clean on a slide. Resources Eventhouse overview Store data in Microsoft Fabric - Decision guide Caching policy (hot and cold cache) Get data overview KQL quick reference Eventhouse and KQL Database consumption Data availability in OneLake Enable Eventhouse endpoint for lakehouse and data warehouse Create an Eventhouse Create a KQL database Real-Time Intelligence tutorial Change data policies Cost breakdown of Eventhouse Manage and monitor an eventhouse Decision guide: Choose the right data store 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.

Apache Airflow in Fabric: When Code-First Orchestration Earns Its Keep Episode 13 • 2026-03-27 Duration: 8:19 When should you reach for Apache Airflow Job instead of Data Pipelines in Microsoft Fabric? Matthias and Fabia break down pool types, cost traps, dbt fragility, and the architectural threshold where visual orchestration breaks down. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways I'm stealing that. But yeah — match the orchestrator to the orchestration complexity. If your workflow fits on a visual canvas, keep it there. Airflow is for when Python is genuinely the clearest way to express your pipeline logic. For maybe... sixty, seventy percent of Fabric workloads, Data Pipeline is the right answer. Airflow earns its spot when you need cross-cloud orchestration, dbt models, complex dependency graphs, or your team already thinks in Python DAGs.... You just paid for a permanent orchestra conductor to wave a baton at six musicians who already know the song. Resources What is Apache Airflow Job? Run a Fabric item using Apache Airflow DAGs Apache Airflow compute in Fabric Apache Airflow job pricing Transform data using dbt Migrate to Apache Airflow job in Microsoft Fabric CI/CD for Apache Airflow in Fabric Apache Airflow Job region availability Quickstart: Create an Apache Airflow Job Apache Airflow Job workspace settings Access Apache Airflow Job Logs Sync a GitHub repository in Apache Airflow Job Run Hello-world DAG in Apache Airflow Job Fabric region availability MS Learn 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.

Copy Job: When Built-In State Management Beats Pipeline Plumbing Episode 12 • 2026-03-20 Duration: 9:54 Copy Job fills the gap between Mirroring's zero-config simplicity and Pipeline's full orchestration control. We break down the architecture, the 2x incremental pricing controversy, V-Order performance traps, and when you should still reach for Pipeline Copy Activity instead. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways Take-home principle. Copy Job is Copy Activity with built-in memory. Same engine, same connectors — it just remembers where it left off. Start with a full load to validate your schema. Switch to incremental once you trust it. And always —... And that's the counterpoint to the counterpoint. Fair question. For a team that already has mature pipeline patterns — control tables, parameterized watermarks, solid error handling — that is a legitimate choice. You pay one-point-five CU across the board and get ForEach loops,... Resources Copy Job Connectors CDC Replication Connectors VNet Data Gateway for Copy Job CI/CD for Copy Job Copy Job Activity What is Copy Job in Data Factory? Create a Copy Job Quickstart: Create a Copy Job CDC in Copy Job (Preview) Copy Job Pricing Monitor a Copy Job Data Movement Decision Guide Data Integration Decision Guide What is Data Factory in Fabric? Pricing Scenario: Copy Job 1 TB CSV to Lakehouse 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.

SQL Database in Fabric — When OLTP Meets Your CU Budget Episode 11 • 2026-03-13 Duration: 9:50 SQL Database in Fabric promises zero-ETL translytical architecture — OLTP writes mirrored to OneLake automatically. But the 15-minute billing window and interactive CU consumption change the math. We break down when it makes sense and when Azure SQL Database plus mirroring is the smarter play. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways That's... a genuinely good architecture. For a lot of teams, that's the right call. You lose zero-config mirroring — you set it up manually — and you lose Git integration and the GraphQL API. But you gain VNet support, CDC, Always... Every. Single. Time. Plus the engine startup needs a two-gig minimum memory allocation. On an F2 capacity, that's... roughly your entire capacity eaten by one database. Technically — yes, that works. But the failure mode I asked about? It's cost. When you create a SQL Database in Fabric, two items appear — the database and a SQL analytics endpoint. Both consume interactive CUs. Not background —... Resources SQL database in Microsoft Fabric — Overview Mirroring Fabric SQL database Translytical applications with SQL database SQL database in Fabric tutorial — End-to-end architecture Data Factory SQL database connector GraphQL API for SQL database Mirroring limitations SQL analytics endpoint Automatic Tuning AI functions Fabric's CI/CD framework Limitations in SQL database in Fabric Feature comparison: Azure SQL Database and Fabric SQL database Billing and utilization reporting for SQL database Mirroring Azure SQL Database to 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.

SQL Analytics Endpoint: Read-Only by Design Episode 10 • 2026-03-06 Duration: 10:53 The SQL Analytics Endpoint gives you T-SQL on Lakehouse data for free — but free comes with metadata sync delays, no Git integration, and silent Direct Lake fallbacks. Matthias and Fabia unpack when to use it, when to reach for a Warehouse instead, and how to avoid the traps that catch most teams. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways So — the take-home. The SQL Analytics Endpoint is a projection, not a database. Use it for what it does brilliantly — SQL access to Delta tables with zero data duplication. But the moment you create your first view, the moment you need... Fair point. And for teams that are SQL-first — BI developers, analysts who live in T-SQL — the Warehouse-only approach has real merit. You lose the zero-setup convenience, you manage a separate item, you pay for writes. But you gain... Hm, let me think... because free has a price. The endpoint runs a background metadata sync process that pauses after fifteen minutes of inactivity. Your next query wakes it up, but now you're waiting for a full resync. And if you've got a... Resources What is the SQL analytics endpoint for a lakehouse? SQL analytics endpoint — Capabilities Decision guide: Warehouse and Lakehouse Refresh SQL endpoint metadata Data types in the SQL analytics endpoint Direct Lake overview Share a Lakehouse Lakehouse overview Warehouse overview SQL Database in Fabric OneLake shortcuts Database mirroring OneLake security Cross-database queries Better together: the lakehouse and warehouse 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.

Fabric Warehouse vs. Lakehouse: Same Storage, Different Engines Episode 9 • 2026-02-27 Duration: 15:34 Matthias and Fabia dissect the Warehouse-vs-Lakehouse decision. They explore why three SQL options exist in Fabric, when the SQL endpoint's read-only design saves you, and why judging Warehouse performance on a cold-cache first query is the mistake everyone makes. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways Today's takeaway. Warehouse and Lakehouse aren't competing products. They're different engines on the same storage. Pick based on workload pattern — T-SQL, multi-table transactions, auto-optimization means Warehouse. Spark, ML,... Fair. And honestly, for a lot of teams that works. If your reporting is read-only — dashboards, DirectLake — the SQL endpoint handles it fine. In a team of eight under cost pressure, Lakehouse plus SQL endpoint might be all you need. The... Right. So here's where people get it wrong. The naive answer is — Warehouse is for SQL people, Lakehouse is for Spark people. Pick your tribe. But that's way too simple. The real difference isn't the language you write. It's who owns the... Resources Warehouse in Fabric Create Warehouse T-SQL surface area Performance Guidelines Better together: Lakehouse and Warehouse Decision Guide: Warehouse vs Lakehouse SQL Analytics Endpoint Performance Result Set Caching Data Clustering Zero-Copy Table Clone Time Travel Transactions Migration from Synapse Architecture Warehouse Team AMA (March 2025) 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.

Mirrored Databases: When Zero-Code Replication Meets Real Architecture Episode 8 • 2026-02-20 Duration: 8:18 Matthias and Fabia explore Fabric mirrored databases — the sweet spot between real-time eventstreams and batch ETL. They unpack CDC replication, the 500-table limit, schema change risks, and why setup simplicity doesn't excuse you from data modeling. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways Today's takeaway — mirroring is the sweet spot between real-time eventstreams and batch ETL. Now — let me steel-man the alternative. Hm, let me think... If your analytics can tolerate live remote queries, shortcuts are genuinely better. No data copy, no replication lag, no storage cost. In a team of eight under cost pressure,... Kind of, yeah. The trap is skipping the data modeling conversation because setup was easy. You still need a medallion layer on top. Mirror gives you bronze — that's it. And your team will absolutely blame the mirror when queries are slow,... Resources Mirrored databases overview Azure SQL DB mirroring Azure SQL DB limitations SQL Managed Instance limitations SQL Server limitations Cosmos DB mirroring Cosmos DB limitations Snowflake mirroring Snowflake limitations Troubleshooting 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.

Data Pipelines: When Orchestration Helps and When It Hurts Episode 7 • 2026-02-13 Duration: 9:53 Matthias and Fabia debate when Fabric Data Pipelines earn their complexity. They unpack the orchestra-conductor mental model, walk through a real green-checkmark-but-no-data failure, and steel-man the case for skipping pipelines entirely. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways That's it. One activity, no dependencies — schedule it directly. Multiple steps with conditional logic — pipeline. But always validate outputs. Never trust the green checkmark without checking row counts. Completely fair. If you have existing ADF, keep using it. ADF connects to Fabric natively — orchestrate Fabric items from ADF, no problem. You get the richer connector library, managed private endpoints today, event-based triggers. For... And your team will absolutely add a pipeline anyway because it feels more 'enterprise. Resources Data Pipelines in Fabric Activity Overview Control flow activities Pipeline Overview Copy Activity Parameters and Expressions Monitor Pipeline Runs Decision Guide: Pipeline vs Dataflow vs Spark Data Integration Strategy Guide Reddit r/MicrosoftFabric MS Q&A Stack Overflow 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.

Spark Job Definitions: Notebooks Are for Humans, SJDs Are for Machines Episode 6 • 2026-02-06 Duration: 10:23 Matthias and Fabia break down Spark Job Definitions in Microsoft Fabric — the production wrapper most teams skip until their scheduled notebook fails at 3 AM. They cover the notebook-to-SJD promotion path, why state leakage kills overnight runs, retry policies, and when a plain notebook schedule is actually fine. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways And wrap it in a Pipeline. Even if just for the alerts. Fair. Solo workflows where the output includes visualizations — scheduled notebook is the right call. The line I draw: the moment a second person depends on that output, or it feeds a downstream system, promote it. Solo analyst with a... Every SJD run starts clean. No leftover variables, no stale session. That's — I mean, that's the whole point. Reproducibility by design, not by discipline. Resources What is a Spark Job Definition? Create SJD Run SJD SJD Git Integration Pipeline SJD Activity Streaming Data into Lakehouse Spark Best Practices Job Queueing Decision Guide: Pipeline vs Dataflow vs Spark Fabric vs Synapse Spark Comparison MS Q&A Reddit r/MicrosoftFabric Stack Overflow 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.

Spark Environments: When Your Starter Pool Isn't Enough Episode 5 • 2026-01-30 Duration: 9:09 Matthias and Fabia dig into Spark Environments in Microsoft Fabric — the dependency management layer most teams adopt too early. They cover the Starter Pool trade-off, why publishing takes fifteen minutes, the SJD gotcha, and when percent-pip install is actually the right call. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways Fair. For pure experiments, percent-pip is the right call — session-scoped, instant, no friction. But across a team? Five people installing different versions every morning. No persistence between sessions. And good luck getting consistent... They just added fifteen minutes to every first session for zero benefit. Because of the publish step. When you create or update an Environment, Fabric resolves every dependency, downloads packages, builds what's basically a container image, and distributes it to compute nodes. That takes five to fifteen... Resources Create and manage environments Configure Starter Pools Manage libraries Environments GA Reddit r/MicrosoftFabric MS Q&A Stack Overflow 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.

Dataflow Gen2: When Power Query Meets Enterprise Scale Episode 4 • 2026-01-23 Duration: 11:20 Matthias and Fabia unpack Dataflow Gen2 — the low-code transformation layer in Fabric. They cover staging architecture, the Gen1-to-Gen2 leap, why your dataflow is slow, multi-destination patterns, and when you should skip the visual editor entirely and reach for a notebook. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways Low-code where you can, full-code where you must. Completely fair. And for teams with strong engineering backgrounds, notebooks are often the right call. But — here's the thing. Not every team has five Python engineers. I've worked with organizations where the data people are Excel and... They get Gen1 performance on a Gen2 label. Resources What is Dataflow Gen2? Dataflow Gen2 architecture Connector overview Power Query M reference Staging settings Incremental refresh Schedule Dataflow Gen2 Best practices Create your first Dataflow Gen2 Monitor Dataflows 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.

Fabric Notebooks: When Interactive Spark Meets Production Reality Episode 3 • 2026-01-16 Duration: 11:26 Matthias and Fabia dig into Fabric Notebooks — the code-first data engineering workhorse. They cover starter pools vs. custom environments, the new native Python mode, the notebook-to-production gap, and why your notebook that runs perfectly at 2pm crashes in the pipeline at 2am. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways Completely fair. And I'll go further — I've seen teams spin up Spark to process ten megabytes of CSV. That's like renting a crane to hang a picture frame. If your transformation is row-level, SQL-expressible, and under a gig? A warehouse... Nope. It's one or the other. And your team will absolutely discover this at the worst possible moment — usually during a demo. The play is: develop and explore on starter pools, switch to a custom Environment only for final testing and... And teams do exactly that. Until they need great_expectations, or dbt-core, or some internal package. Starter pools give you the default library set — pandas, scikit-learn, plotly, the usual. But the moment you need anything custom, you... Resources What is a notebook? Python experience in notebooks Configure Starter Pools Lakehouse and notebooks Data Wrangler Manage libraries Schedule notebook High Concurrency mode VS Code extension Spark Job Definition Notebook best practices Author and execute notebooks Notebook visualization 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.

OneLake Shortcuts: Virtual Pointers, Real Tradeoffs Episode 2 • 2026-01-09 Duration: 9:21 Matthias and Fabia break down OneLake shortcuts — virtual pointers that unify multi-cloud data without copies. They cover the read-write boundary, the shared credential security model, caching economics, and when a good old copy is actually the better architecture call. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways That's it. Don't shortcut the architecture thinking just because the feature is called Shortcut. Completely fair. And in plenty of cases, that IS the right answer. I mean, architecture is not religion — if a nightly copy gives you better performance, lower cost, and simpler security? Do that. Shortcuts shine when data governance says... Security model. External shortcuts use stored credentials — one credential, shared by everyone who accesses that shortcut. That's a fundamentally different security posture than internal shortcuts, where your own identity passes through.... Resources OneLake Shortcuts Shortcut types Where to create shortcuts Shortcut authorization Shortcut caching Limitations Shortcut security Create OneLake Shortcut Create ADLS Gen2 Shortcut Create S3 Shortcut Create GCS Shortcut Shortcuts REST API On-premises Shortcuts Dataverse Shortcuts OneLake Overview 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.

Lakehouse Architecture: One Storage Layer, Zero Excuses Episode 1 • 2026-01-02 Duration: 8:28 Why the Fabric Lakehouse isn't a set-and-forget data platform. Matthias and Fabia unpack the real architectural tradeoffs — medallion layers, Delta table maintenance, Direct Lake, and when a Warehouse is actually the better call. What we discuss A real-world mistake from a pre-Fabric era The one question that reframes the architectural debate How we got here — predecessor products and evolution Why the "obvious" answer is often wrong A real Reddit/Microsoft Q&A question unpacked The concrete recommended architecture F-SKU realism — what this actually costs When the rejected approach is actually right Risks of the recommended path What Microsoft is shipping that changes the calculus The architectural principle to take home Key takeaways That's the whole lesson. Don't architect for the demo. Architect for month six. Completely valid choice. If your team is SQL-first, no Spark needed, no ML — the Warehouse might genuinely be the better call. Pick the tool that matches the team and the workload, not the one that looks most impressive on the architecture slide. Fair. Not a trap — a tradeoff. You get Spark, flexibility, streaming and batch in one place. But you own the maintenance. That's the deal. Resources Lakehouse end-to-end scenario Tutorial: Create a lakehouse Medallion architecture for Fabric Tutorial: Ingest data SQL analytics endpoint Direct Lake overview Delta Lake table optimization Decision guide: Lakehouse vs Warehouse High Concurrency Mode Lakehouse overview Table maintenance Work with Delta Lake tables Organize with Medallion architecture Use Apache Spark in Fabric Greenfield Lakehouse on 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.

Welcome to the Fabric Architecture Podcast Episode 0 • 2026-01-01 Duration: 3:47 Meet Matthias Falland and his AI co-host Fabia. Learn what this show is — anonymized real customer architecture decisions, cost realism, counter-arguments included — and what it is not. Weekly episodes, aligned with Fabric Friday recordings. Key principles of the show Architecture is not religion. Pattern dictates platform. Simplicity on the slide is not simplicity at runtime. In a team of eight under cost pressure... 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.