There’s a moment in almost every machine learning project where the exciting part ends and the painful part begins.
The exciting part is building the model. Weeks of experimenting, tweaking hyperparameters, watching accuracy climb – genuinely fun work. Then the model hits a threshold that satisfies everyone, and the team moves on.
The painful part comes a few weeks later, when the questions start.
Which version is running in production right now? What data did we train it on? Why are the predictions suddenly different? Can we reproduce what we had last month?
These sound like simple questions. They’re not. In my experience, answering them is often harder than building the model in the first place – and that’s a problem nobody anticipated when they started the project.
MLflow exists because of exactly this problem.
What ML Without MLflow Actually Looks Like
Picture a typical workflow with no tooling in place.
A data scientist finishes training, saves a pickle file, and shares it through whatever channel happens to be convenient – cloud storage, email, a Slack message.
python
import pickle
with open("model.pkl", "wb") as f:
pickle.dump(model, f)
A few weeks pass. A new version gets trained. Then another. Now the folder looks like this:
model.pkl
model_v2.pkl
final_model.pkl
final_model_new.pkl
final_model_latest.pkl
Nobody is completely sure which one production is actually using.
Add a few more engineers to the mix and things deteriorate fast. Experiments live in separate notebooks. Metrics get pasted into spreadsheets. Model artifacts are scattered across different machines and storage buckets. It’s not that people are careless – it’s that there’s no system holding any of it together.
This works fine for a solo project or a quick prototype. It falls apart the moment the work gets serious.
Why ML Is Harder to Track Than Regular Software
Software engineers have version control. A Git history tells you exactly what changed, when, and why.
Machine learning doesn’t map neatly onto that model, because a model isn’t just code. It’s a combination of things that all need to be tracked together – the training code, the dataset and which version of it, feature engineering decisions, hyperparameters, the actual model artifact, environment dependencies, evaluation metrics, and deployment configuration.
Imagine someone asks you to explain why your churn prediction model made a specific decision six months ago. To answer properly, you’d need all of the above. Not just the model file – everything that went into producing it.
Without proper tracking, that kind of question becomes genuinely unanswerable. Which is a bad situation to be in when a business stakeholder is waiting.
What MLflow Actually Does
MLflow treats models as managed assets rather than standalone files. Alongside the model itself, it stores the context – parameters, metrics, artifacts, lineage – that makes the model meaningful and reproducible.
MLflow essentially handles four things that ML teams always struggled with – keeping track of what you tried in experiments, packaging models so they’re actually portable, versioning those models like you’d version code, and deploying them without reinventing the wheel every single time.
And the key word across all of it is consistent. MLflow’s real value isn’t any one of these features in isolation – it’s that they work together across the full lifecycle, from the first messy experiment all the way to production.
Where It Fits in the Pipeline
The way I think about it: data comes in, gets engineered into features, a model gets trained, and then the messy part starts – someone has to track what worked, package it properly, get it registered somewhere sensible, deploy it, and then actually watch it in production. MLflow is designed to touch all of those stages, not just one.
That last point – touching deployment, not just experimentation – matters more than people initially realize.
Why Databricks and MLflow Are So Intertwined
MLflow wasn’t created by a third party and later adopted by Databricks – Databricks built it. That context explains why the integration feels native rather than bolted on.
As organizations scaled their ML programs, they needed a platform that could handle the full lifecycle without requiring engineers to switch tools at every stage. Databricks built that vision into the platform from the start, and today MLflow threads through Experiments, Unity Catalog, Feature Engineering, Model Registry, Model Serving, and governance tooling. Moving from experiment to production is meant to feel like a continuous process rather than a series of awkward handoffs between teams.
Experiment Tracking Is the Entry Point, Not the Whole Story
Most people discover MLflow through experiment logging. Something like:
python
mlflow.log_metric("accuracy", 0.92)
That’s useful. But it’s also just scratching the surface.
Experiment tracking is the obvious starting point – logging parameters and metrics so you actually know what you ran. But packaging, registry management, and deployment tooling matter just as much once you’re past the notebook phase.
Once you’ve got fifteen models spread across three teams, you’ll understand why having one consistent deployment pattern is worth almost any tradeoff.
What Happens When Your “Model” Isn’t Really a Model
This is where things get interesting – and where most conventional model-serving tools start to struggle.
The inference logic on one project I worked on had input validation, a data enrichment step that hit an external API, a layer of business rules that the ML model knew nothing about, and then some post-processing before anything went back to the user. The actual trained model was almost a footnote in the whole pipeline.
Packaging that entire workflow as a single deployable artifact – rather than stitching together five different deployment approaches – is exactly what MLflow’s PyFunc framework made possible. You can wrap almost any Python-based prediction logic into something the platform treats like any other model. Custom logic, third-party services, hybrid workflows – it doesn’t matter.
That flexibility is probably MLflow’s most underappreciated capability, and honestly the reason I’d recommend it to teams even when they think they don’t need it yet.
