Subscribe
Share
Share
Embed
Fabric ML Model wraps an MLflow registry inside your workspace — batch scoring to Power BI with zero refresh sounds ideal. But the real-time endpoints are Preview, Git tracks metadata only, and there's no GPU. When does this actually replace Azure ML, and when does it just sit next to it?
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?
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.
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.
Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.
Your Endpoint Falls Asleep After Five Minutes
Episode 22 | 2026-05-29
Fabric Architecture Podcast | Hosted by Matthias Falland with AI co-host Fabia
---
[00:08] Fabia: Eleven batch flavors. Four real-time flavors. And the real-time endpoint falls asleep after five minutes idle.
[00:15] Matthias: Five minutes. That's barely enough to pour a coffee.
[00:18] Fabia: That's the scoring infrastructure Microsoft built to operationalize your ML models inside Fabric.
[00:25] Matthias: So here's the question every team lands on — do I move my models into Fabric, or keep them where they are?
[00:32] Fabia: Fabric ML Model is an MLflow registry inside your workspace. You train in notebooks — sklearn, LightGBM, XGBoost, whatever fits the problem. MLflow autolog captures your parameters, your metrics, and critically, the model signature. Then you register the best run as a versioned model. Four layers deep: experiment contains runs, a run produces a registered model version.
[00:57] Matthias: The signature keeps coming up. How often does a missing one actually bite?
[01:02] Fabia: It's the number-one first-deployment failure in the community forums. PREDICT requires a populated MLflow signature — a mapping of your input columns to your output columns. Without it, PREDICT won't start. The fix is one line: mlflow dot autolog with exclusive equals false. Captures the signature automatically from your training data.
[01:24] Matthias: One line that nobody writes the first time.
[01:27] Fabia: The integration earns its keep right here. PREDICT writes predictions to a Delta table in your Lakehouse. A Power BI semantic model in Direct Lake mode reads that table directly — zero data movement. Your notebook scores the model, predictions land in OneLake, and Power BI sees them without scheduling a refresh.
[01:48] Matthias: No refresh at all? That genuinely changes the economics. Every batch scoring pipeline I've dealt with ends with that same ETL hop — score, export, load into some staging table, schedule a refresh, hope it runs before the morning standup. That's usually where someone's weekend evaporates.
[02:08] Fabia: The whole loop runs in one workspace, one capacity, one set of governance. Predictions and source data share the same OneLake.
[02:16] Matthias: What about schema changes? If my prediction notebook adds a column, does Direct Lake just pick it up?
[02:23] Fabia: Schema changes need a manual refresh on the semantic model — a schema refresh, not a data refresh. One click in Power BI, it re-reads the column structure, done. The data itself never moves.
[02:35] Matthias: That loop is what keeps pulling teams in. A data engineer can train, register, score, and see results in Power BI without leaving the workspace. I keep running into teams where that closed loop is the entire reason they moved to Fabric.
[02:51] Fabia: It holds as long as your requirements stay inside two boundaries — tabular models and batch scoring. Step outside either one, and the gaps start compounding.
[03:02] Fabia: We got a question that tests exactly where those boundaries sit. Our team has been on Azure Machine Learning for two years. Now leadership wants to consolidate on Fabric. Is Fabric ML Model a real replacement? What do we lose, what do we gain?
[03:19] Matthias: That conversation never has a clean answer. It depends on what your models actually need, and what your team can actually support — most teams haven't inventoried either one before someone in leadership says consolidate.
[03:34] Fabia: Start with compute. Fabric notebooks don't have native GPU. If you're training anything beyond tabular — vision, NLP, transformer fine-tuning — you can't train it here. That's a permanent design boundary.
[03:47] Matthias: Every vision project, every fine-tune —
[03:50] Fabia: Stays on Azure ML or Databricks.
[03:52] Matthias: That's a bigger carve-out than most teams expect.
[03:55] Fabia: And it gets sharper at the operational layer. Git integration for ML models is Preview, and it tracks metadata only. What lands in your repo is display names and lineage pointers. Your trained weights and experiment artifacts stay in workspace storage. You cannot git pull to retrieve a model.
[04:15] Matthias: Wait — the artifacts aren't in the repo? That rewrites the CI/CD playbook. Every ML team I've worked with treats the model artifact as the deployable unit. If your deployable unit lives outside version control, you're versioning the recipe and shipping the cake by hand.
[04:33] Fabia: And Model Endpoints are Preview with real constraints. Four flavors: Keras, LightGBM, Sklearn, XGBoost — AutoML support has since been added. Maximum five active versions per model, auto-sleep after five minutes idle, and if you want blue-green deployments or autoscale, you're looking at the wrong platform.
[04:54] Matthias: So the five-minute number from the top — that's your production endpoint going cold between API calls.
[05:01] Fabia: What the Azure ML teams don't say out loud: standing up a separate managed ML platform with its own compute lifecycle and connector plumbing back to your analytics layer is weeks of engineering before anyone trains a model. And you're paying for that compute whether the GPUs are warm or idle.
[05:20] Matthias: That's real. The teams where Fabric ML Model genuinely wins aren't the ones with mature ML platforms. They're the ones where a data engineer got a Jira ticket that says build a churn model and they've never provisioned a GPU cluster. Staying in the workspace they already know is the only realistic path to production.
[05:41] Fabia: On cost — training and scoring both consume your Fabric capacity, your F-SKU. There's no separate ML compute bill, which sounds like savings until you realize your training job competes with every other workload on the same capacity. On a smaller capacity SKU, a long training run can starve the whole workspace.
[06:02] Matthias: And nobody discovers that on a Tuesday afternoon when the capacity's idle. They discover it on a Friday when twelve reports are refreshing and the churn model decides to retrain.
[06:14] Fabia: Azure ML lets you spin up a training cluster that exists only for the duration of the job and then tear it down. Fabric capacity is shared and always on. Your ML workload uses whatever headroom is left.
[06:28] Matthias: Here's the recommendation I'd stand behind. If your models are tabular, your data's in OneLake, and your consumers are on Power BI — move them. The Direct Lake loop alone justifies the effort. But keep Azure ML for GPU training and production-grade real-time endpoints. The hybrid works because both sides speak MLflow — same registry protocol, different deployment surfaces.
[06:53] Fabia: The risk to flag: Model Endpoints are Preview. If you build a real-time integration against them today and Microsoft changes the API surface or activation behavior at GA, you're retrofitting production code. Pin your batch deployments to specific model versions, and don't treat Preview features as load-bearing walls.
[07:14] Fabia: Show me the query pattern. Batch to Power BI? That's Fabric's territory. Real-time REST with an SLA? That's still Azure ML.
[07:22] Matthias: And if you've got both, run both. Same MLflow protocol on either side.
[07:27] Fabia: Somewhere right now, a data engineer just ran register_model for the first time. The version number incremented. The signature field is empty. And PREDICT is about to have a conversation with them.
[07:41] Matthias: It's a short conversation.
[07:43] Matthias: If you're weighing that decision — DM me on LinkedIn. Find me as Matthias Falland.
[07:48] Fabia: Architecture is not religion.
---
End of episode. ~07:50 estimated.