MLflow, feature tables, Model Serving and monitoring
MLOps on Databricks, from feature table to monitored endpoint
We set up MLOps on Databricks for the models you already have.
Feature tables in Unity Catalog with point-in-time training sets, MLflow 3 tracking with models registered in Unity Catalog, an evaluation gate before Model Serving, data profiling for drift on what the endpoint predicts, and a retraining job on Lakeflow Jobs that someone other than the model's author can run.
- Who it is for
- ML leads and heads of data science whose models stop at the notebook
- Bench
- 115+ engineers, 80 Databricks-certified
The model works. It's worked in a notebook for four months, the person who built the training set has moved to another project, and nobody can say which version the dashboard is reading. We start with one model, end to end, usually two to six weeks depending on how its features were built.
What we look at first
- Where each model's features are computed, and whether training and serving compute them the same way
- Whether the training set behind the live model can be rebuilt as it stood on the day it was trained
- How the live version is recorded, and who can change it
- What the endpoint logs, and whether anything reads it
- Who retrains, how often, and what tells them to
- What the endpoints cost, from system.billing.usage
What we build
- Feature tables in Unity Catalog with a primary key and a timeseries column, so a training set is a point-in-time lookup
- Models logged with the feature engineering client, so the endpoint looks features up itself
- Every model registered in Unity Catalog, with a champion alias marking the live version
- An evaluation gate before promotion, as a deployment job where its Public Preview status suits you
- Model Serving endpoints with inference tables, unpacked into a table a data profiling monitor reads
- A retraining job on Lakeflow Jobs, on a schedule first and on drift once there's history, with a written rollback
How the parts fit together
A lot of what's written about MLOps on Databricks is out of date now. The workspace Feature Store is deprecated and only exists in workspaces created before 19 August 2024; features belong in Unity Catalog, where any Delta table with a primary key is a feature table. Legacy online tables stopped working in January 2026, and the Online Feature Store, which runs on Lakebase, replaced them. Lakehouse Monitoring is called data profiling now.
MLflow 3 made the logged model an object of its own, so a version's evaluation metrics sit on its page in Unity Catalog. Deployment jobs, in Public Preview, run evaluation, approval and deployment each time a version is registered. Lakeflow Jobs also has a model update trigger, in Beta, that starts a job when a version is created or an alias moves.
For drift on the inputs, set ENABLE_FEATURE_TRACING on the endpoint before launch. Without it the features the endpoint looked up for itself never reach the inference table, and there's nothing to profile but the prediction.
Checked on 12 October 2026 against time series feature tables, the workspace Feature Store, the Online Feature Store, MLflow 3, deployment jobs, Lakeflow Jobs triggers, serving endpoints, inference tables on serving endpoints, logging looked-up features and data profiling.
A training set you can rebuild, and an alias you can move
The training set looks features up as of each label's own date, so rerunning it in six months gives the same rows, provided nobody rewrites the feature table's history; where an audit depends on it, we save the training set as a table as well.
Logging through the feature engineering client is what lets the endpoint fetch the features itself at request time. It returns nothing, so the run's own artifact is registered directly, which hands back the exact version that was evaluated, and only after that evaluation passes does the endpoint move to it and the champion alias follow.
The endpoint pins a version; the alias records which one, so moving the alias alone changes nothing that's serving. The label and timestamp columns are excluded from the model's inputs, so a caller sends a customer ID and nothing else.
from databricks.feature_engineering import FeatureEngineeringClient, FeatureLookup
from mlflow import MlflowClient
import mlflow
mlflow.set_registry_uri("databricks-uc")
fe = FeatureEngineeringClient()
training_set = fe.create_training_set(
df=labels, # customer_id, as_of, churned
feature_lookups=[
FeatureLookup(
table_name="ml.features.customer_daily",
lookup_key="customer_id",
timestamp_lookup_key="as_of",
)
],
label="churned",
exclude_columns=["customer_id", "as_of"],
)
model = train(training_set.load_df())
with mlflow.start_run() as run:
fe.log_model(
model=model,
artifact_path="model",
flavor=mlflow.sklearn,
training_set=training_set,
)
version = mlflow.register_model(f"runs:/{run.info.run_id}/model", "ml.models.churn").version
# after this exact version's evaluation passes, update the serving endpoint
# to this version (an endpoint pins a version), then record it as the champion:
MlflowClient().set_registered_model_alias("ml.models.churn", "champion", version)Checked on 12 October 2026 against training with feature tables, the FeatureEngineeringClient reference and models in Unity Catalog.
Issued by Databricks to the engineers
What makes it faster
When the question is whether a new model is actually better, Experiments runs the comparison: A/B tests and quality gates on Databricks and MLflow, so promotion is decided by a result rather than an opinion.
About TechFabric ExperimentsWhere this goes next
FAQ
Databricks MLOps: common questions
How long does it take to set up MLOps on Databricks?
For one model, two to six weeks, and most of the variation is how the features were built. Features computed in a notebook on one laptop take the longest to move. After the first model the rest go faster, because the feature tables, the registry conventions, the gate and the monitor already exist.
What is the Databricks Feature Store now?
Feature engineering in Unity Catalog. A Delta table with a primary key is a feature table, governed and traced through lineage like any other. Point-in-time training sets need one timestamp key marked TIMESERIES, and an endpoint reads the latest values from the Online Feature Store on Lakebase. The code on this page shows the lookup.
How does Databricks Model Serving work?
It puts a registered model behind a REST endpoint, POST /serving-endpoints/{name}/invocations, on serverless compute. One endpoint can serve two versions and split traffic between them by percentage, which is how we compare a challenger against the live model on real requests.
Scale to zero saves money on quiet endpoints, and Databricks recommends against it for production because of the cold start.
What happened to Lakehouse Monitoring?
It's called data profiling now, part of data quality monitoring next to anomaly detection. An inference profile reads a table of predictions with the model ID, the prediction and a timestamp, and writes a profile metrics table and a drift metrics table per window. Serving logs requests as JSON, so we unpack them into that shape first.
What changed in MLflow 3?
The logged model became an object of its own, carrying metrics, parameters and traces across runs, so a version's evaluation sits on its page in Unity Catalog. Deployment jobs arrived, in Public Preview, to evaluate, approve and deploy each new version. mlflow.evaluate is deprecated in favour of mlflow.models.evaluate and, for generative AI, mlflow.genai.evaluate.
Should we move machine learning onto Databricks from SageMaker or Azure Machine Learning?
Only if the data is already there or going there. A model trained on Databricks reads its features where the tables live, under the same grants, which is the strongest reason.
If the data stays elsewhere, the serving platform matters less than having the feature store, the registry, the gate and the monitor in place, and we'd do that where the model is.
The rest of databricks
Databricks consulting
Data and engineering leaders choosing a Databricks partner
Hire Databricks engineers
Engineering and data leaders who need Databricks capacity quickly
Lakebase implementation
Data and product leaders putting an operational workload on Databricks
Unity Catalog consulting
Platform and security leads who have to defend the setup to somebody else
Databricks cost optimization
Data platform leads whose Databricks bill is outgrowing the work
Data integration
Data, finance and operations leaders whose numbers live in five systems
Databricks data engineering
Data and analytics leaders running pipelines on Databricks, or moving onto it