Subscribe
Share
Share
Embed
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?
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.
Speaker 1
Architecture decisions for Microsoft Fabric. This is the Fabric Architecture Podcast Welcome back to Fabric Architecture Podcast. Matthias Falland here and with me Fabia, your AI co-host
Speaker 2
Built on 11 Labs voice synthesis.
Speaker 1
New episode every Friday. Today, ML models in fabric. Not the training part everyone leads with. the part that actually kills production deployments, where your model lands after training, and whether fabric belongs in that decision at all.
Speaker 2
Episode 22. And the question I keep seeing is not, how do I use Fabric ML model? It's should I? Very different conversations.
Speaker 1
Let me confess something. 2022 Synapse Analytics Project Client had a solid Azure Machine Learning Workspace. Trained models managed endpoints, full ML op setup Leadership says, let's consolidate into Synapse. Three weeks trying to make Synapse ML behave like Azure ML It didn't. Then Fabrics Data Science Workload shipped at Build 2024 with an actual ML model item. And I watched three teams try the exact same consolidation move. Great, we can retire Azure ML now. Same conversation three times.
Speaker 2
What's the conversation? What do you lead with?
Speaker 1
One question. Where are your predictions going? Power BI or an application? So the ML model item landed with Fabric Data Science at Build 2024. Before that, Microsoft's story was Azure Machine Learning with its own workspace and cluster overhead, or Databricks with native MLflow Synapse had some ML integration but honestly thin. Fabrics ML model takes MLflow registered models. puts them inside your workspace, layers on fabric governance, endorsement, sensitivity labels, lineage, and gives you two deployment surfaces. Same MLflow API you already know.
Speaker 2
The item is new, the protocol is familiar. But the deployment surfaces are where the assumptions collapse.
Speaker 1
Right. Naif read. Fabric has ML models, Fabric has endpoints, therefore I retire Azure ML. That's wrong. Model endpoints are preview, four supported flavors, auto sleep after five minutes idle, max five concurrent active versions Azure ML Managed Endpoints, Blue Green, Autoscale, GPU Backing, No Auto Sleep. Those are not equivalent.
Speaker 2
And yet, the One Lake integration is genuinely better on the fabric side?
Speaker 1
For Power BI shops, yes. Predict writes predictions to a delta table in one lake. 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.
Speaker 2
Which is exactly the tension in a question that shows up on R slash Microsoft Fabric basically every week. The post reads, Our team has been on Azure machine learning for two years.
Speaker 1
Now leadership wants to consolidate on fabric. Is Fabric ML model a real replacement? What do we lose? What do we gain? Okay, so four layers in the registry. Experiment, run, ml model, version. The version is what you deploy and each version carries a model signature, the typed contract between training and scoring. No signature, predict refuses. One line fixes it. mlflow. autolog with exclusive equals false. Captures the signature automatically. That's the canonical fabric idiom.
Speaker 2
So the signature is the gate between experimentation and operationalization.
Speaker 1
Exactly. And from one ML model you get two scoring surfaces. Predict for batch, 11ml flow flavors, GA, writes predictions to one lake, direct lake, reads the delta table with no copy, no refresh. Model endpoints for real-time, four flavors, REST API, auto sleep after five minutes idle. Still preview. First request after sleep has wake up latency. Plan for that.
Speaker 2
Pattern dictates platform. Batch output, Power BI consumers, predict wins. Single record rest API. Endpoints. But the wake-up cost is real, and your SLA will feel it.
Speaker 1
And your team will blame the network.
Speaker 2
Quick note for new listeners. My voice, Fabia, is designed. Matthias's voice, cloned. Built on 11 Labs voice synthesis. Transparent by design.
Speaker 1
Cost picture. The ML model item has no separate overhead. You're paying for fabric capacity. Training runs spark on your FSKU. Model endpoints consume capacity when active Auto sleep is a cost feature, not a bug. Practical levers. Run predict in scheduled notebooks off-peak. Size your spark pool to what finishes in the window Deactivate stale endpoints before you hit the 5-version ceiling.
Speaker 2
Hmm. Let me Steel Man staying on Azure Machine Learning. GPU Compute for Training. Managed endpoints with blue-green canary auto scale, no auto sleep. Full audit logs and arm level R back. For a regulated shop or a team training vision models, fabric genuinely cannot match that today.
Speaker 1
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, register via ML Flow Protocol, deploy to fabric for the one leg batch loop. Same MLflow API on both sides. Interop works.
Speaker 2
Two concrete risks before we move on.
Speaker 1
First, predict signature trap. You train, register, run, predict. Fails with a signature error. Took a client three hours to find it on first deployment. Fix always mlflow. autolock exclusive equals false. One line. Non-negotiable.
Speaker 2
Second risk?
Speaker 1
The sixth endpoint. You activate version 8, you get an error. Max 5 concurrent active versions per ML model. And your team will absolutely blame the network. Deactivate an older version first. The limit is documented. People still hid it.
Speaker 2
Two roadmap items worth watching. Git integration for ML experiments and models. Preview now. Tracking metadata only. Display name, version, lineage. Runs and model files stay in workspace storage. As this matures toward GA, dev test prod promotion gets cleaner And model endpoints flavor coverage. 4 today against 11 in predict. That gap is the one to track.
Speaker 1
The metadata only git behavior is what I watch most. The pattern that works right now. Git for code, notebooks, scripts, configs. Workspace storage for data runs model versions, lineage stitches them. If Git integration matures to actually move model artifacts That's when the MLOP story becomes genuinely competitive.
Speaker 2
So, the take-home principle?
Speaker 1
Where do the predictions land? That question answers the architecture. One Lake 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, Strict MLObs Audit Trail, Azure ML, no question The platform follows the pattern.
Speaker 2
I want to flip it. New project, blank slate, no existing ML platform. What's your default?
Speaker 1
Hmm, if data's going into one leg anyway, and in a fabric shop it usually is, I'd start with Fabric ML model. Lower friction, the Power BI loop is real. I'd bring Azure ML in when I hit a specific wall, GPU, advanced endpoints, audit requirements. Which means I'd bring it in eventually, but not on day one. That's episode 22. DM me on LinkedIn. Find me as Matthias Falland. Architecture questions, platform decisions you're wrestling with, war stories, I read them all This was the Fabric Architecture Podcast. Thanks for listening.