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 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

• 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 Experiment
• Notebooks
• Lakehouse
• Direct Lake
• Code-first AutoML
• Low-code AutoML
• SynapseML
• Activator
• Machine learning model in Microsoft Fabric
• What is Data Science in Microsoft Fabric?
• Tutorial Part 3: Train and register a machine learning model
• Tutorial Part 4: Perform batch scoring and save predictions
• Machine learning model scoring with PREDICT
• Serve 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.

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 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

• 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 limitations
• CloudEvents 1.0
• Use schemas in eventstreams
• Real-Time Hub Schemas
• Business Events Concepts
• Consume Business Events from Activator
• Eventhouse
• Confluent Kafka source
• Schema Registry in Fabric Real-Time Intelligence (preview) — Overview
• Create and manage event schema sets
• Create and manage event schemas in schema sets
• EventSchemaSet REST API definition
• Eventstream Overview — Schema Management section
• Multiple-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.

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 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: 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 Eventstream
• Activator from KQL Queryset
• Activator from RTD
• Activator from Power BI
• Real-Time Hub Set Alerts
• Set Alerts on Anomaly Detection
• What is Fabric Activator?
• Tutorial: Create and activate a Fabric Activator rule
• Create a rule in Fabric Activator
• Trigger modeling in Activator
• Fabric Activator rules
• Detection conditions
• Activator Limitations
• Latency in Activator
• Activator 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.

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 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

• 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 Database
• KQL Queryset
• Real-Time Hub
• Activator on RTD
• Anomaly Detection
• Power BI + KQL
• Fabric Map
• What is Real-Time Dashboard?
• Create a Real-Time Dashboard
• Real-Time Dashboard Permissions
• Use Parameters in Real-Time Dashboards
• Customize Real-Time Dashboard Visuals
• Activator Limitations
• Generate Real-Time Dashboard with Copilot
• Copilot-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.

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.

Episode 17 • 2026-04-24 Duration: 9:39

Matthias 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 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 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 —...

Resources

• Query data in a KQL queryset
• Create a KQL queryset
• Kusto Query Language overview
• SQL to KQL cheat sheet
• KQL quick reference
• make-series operator
• series_decompose_anomalies()
• Anomaly detection and forecasting
• Time series analysis
• render operator
• Share KQL queries
• Create a Real-Time Dashboard
• Real-Time Intelligence tutorial part 5: Query streaming data using KQL
• Tutorial: Learn common operators
• Tutorial: Use aggregation functions

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.

Episode 16 • 2026-04-17 Duration: 10:26

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.

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

• If 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?

Resources

• What is Real-Time Intelligence?
• Choose an analytical data store in Microsoft Fabric
• Eventhouse overview
• Data connectors overview
• Get data overview
• Change data policies
• KQL overview - scalar data types
• Eventhouse and KQL Database consumption
• Pricing cost drivers
• Create a KQL database
• Time series analysis
• Anomaly detection and forecasting
• Manage and monitor a database
• Manage and monitor an eventhouse
• KQL Database git integration

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.