# Databricks MLOps

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

For: ML leads and heads of data science whose models stop at the notebook
Canonical: https://www.techfabric.com/databricks/mlops

---

MLOps on Databricks, from feature table to monitored endpoint

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

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

- 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](https://docs.databricks.com/aws/en/machine-learning/feature-store/time-series), [the workspace Feature Store](https://docs.databricks.com/aws/en/machine-learning/feature-store/workspace-feature-store/), [the Online Feature Store](https://docs.databricks.com/aws/en/machine-learning/feature-store/online-feature-store), [MLflow 3](https://docs.databricks.com/aws/en/mlflow/mlflow-3-install), [deployment jobs](https://docs.databricks.com/aws/en/mlflow/deployment-job), [Lakeflow Jobs triggers](https://docs.databricks.com/aws/en/jobs/triggers), [serving endpoints](https://docs.databricks.com/aws/en/machine-learning/model-serving/create-manage-serving-endpoints), [inference tables on serving endpoints](https://docs.databricks.com/aws/en/ai-gateway/inference-tables-serving-endpoints), [logging looked-up features](https://docs.databricks.com/aws/en/machine-learning/model-serving/store-env-variable-model-serving#log-feature-lookup-dataframes-to-inference-tables), [data profiling](https://docs.databricks.com/aws/en/lakehouse-monitoring/).

## 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)
```

Python, databricks-feature-engineering with MLflow 3 on Unity Catalog. Checked against the feature engineering API reference on 12 October 2026.

Checked on 12 October 2026 against: [training with feature tables](https://docs.databricks.com/aws/en/machine-learning/feature-store/train-models-with-feature-store), [the FeatureEngineeringClient reference](https://api-docs.databricks.com/python/feature-engineering/latest/feature_engineering.client.html), [models in Unity Catalog](https://docs.databricks.com/aws/en/machine-learning/manage-model-lifecycle/).

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