What is MLOps on Databricks in 2026?

MLOps on Databricks is the operational discipline applied to ML and GenAI workloads on the platform, CI/CD for models, model serving, monitoring, lineage, and the governance that lets you ship and operate AI systems with the same rigor as any other production code.

How do I version control my Databricks notebooks and ML code?

Databricks Repos integrates with GitHub, GitLab, Azure DevOps, and Bitbucket. Notebooks live as code in your repo. Production deploys come from version-controlled bundles, not interactive notebooks. Asset Bundles (DABs) are the recommended packaging in 2026.

How does model deployment work?

Trained models are registered to the Unity Catalog Model Registry. Deployment promotes a registered model version to a Model Serving endpoint. Standard patterns, blue-green, traffic splitting, canary, are supported. Rollback is a single API call.

How do I monitor production models?

Three layers: (1) serving-level metrics (latency, error rate, throughput) via the Databricks UI; (2) prediction monitoring (output distribution, prediction drift) via Lakehouse Monitoring; (3) quality monitoring against ground truth when available. Alerts wire into the standard incident systems.

How is GenAI MLOps different from traditional MLOps?

Most differences are in evaluation rather than process. Classical ML monitors precision/recall; GenAI monitors faithfulness, relevance, and groundedness, which require LLM-as-judge evaluation rather than direct metric calculation. The pipeline shape is similar; the metrics are different. MLflow Evaluate handles both.

What is a Databricks Asset Bundle (DAB)?

An Asset Bundle is the recommended way to package Databricks projects, notebooks, workflows, ML pipelines, model deployments, as a versionable, deployable unit. DABs replace the older mix of ad-hoc deployment scripts with a single declarative format.

Topic guide

· Covered in Volume 4 · The AI Lakehouse

MLOps on Databricks: The 2026 Operational Playbook

MLOps is the discipline that turns Databricks notebooks into production AI systems. In 2026 the playbook centers on Asset Bundles, Unity Catalog, Model Serving with the AI Gateway, alias-driven promotion, and Lakehouse Monitoring. This is the operational reality, written for engineers who have to make it work.

10 min read Updated 2026-05-18 By Ritesh Modi

Most ML projects fail at the same place: the gap between a working notebook and a system that runs every day, recovers from its own failures, and produces consistent answers under changing data. MLOps is the discipline that closes that gap. On Databricks in 2026, the toolchain has consolidated enough that there's now a defensible reference implementation.

The four production responsibilities

Independent of platform, a production ML system has four responsibilities:

Reproducibility, anyone on the team can rebuild a model bit-for-bit from version control.
Deployment, models reach production through a versioned, reviewable process.
Monitoring, production behavior is observable and changes trigger alerts.
Governance, who deployed what, when, and under what authority is recorded.

On Databricks 2026, each maps to specific primitives.

Reproducibility: Asset Bundles and the Repo

The reproducibility story starts with code in version control. Databricks Repos provides the Git integration, notebooks live as files in GitHub or equivalent. Asset Bundles (DABs) provide the packaging: a declarative YAML manifest that describes notebooks, workflows, model deployments, and their dependencies.

A bundle is the unit of deployment. The same bundle that an engineer runs locally is what gets deployed to staging and then production. No "but it worked in my notebook", if it works in your bundle, it works in CI, it works in prod.

The 2026 pattern: every project is a bundle. Notebooks are in source control. Deployment is databricks bundle deploy from CI, not a click in the UI.

UC model with many immutable versions; three aliases (@dev @staging @prod) point at versions; promotion is alias movement — Figure 48.1 · Volume 4, Chapter 48 Promotion is alias movement, not redeploy. Every caller reads its alias, never a version number. Change the alias, change what every caller sees, including rollback, in seconds.

Deployment: Model Registry → Model Serving

The deployment pipeline:

Training job logs a model run with MLflow.
If evaluation passes, the model is registered to the Unity Catalog Model Registry.
An alias (e.g., @candidate) is set on the new version.
A staging deployment promotes the candidate to @staging and routes a slice of traffic.
If staging metrics hold, promotion to @production is a single alias move.

Rollback works the same way: move the @production alias back to the previous version. Model Serving picks up the change without a restart. Standard patterns, blue-green, canary, traffic splitting, all supported.

The Unity Catalog piece matters here. The registry isn't a side database; it's a first-class catalog object with the same ACLs and lineage as your data. "Who deployed what" is auditable out of the box.

The monitor-to-retrain loop: data and model monitors trigger evaluation, which gates an automated retrain job — Figure 49.2 · Volume 4, Chapter 49 The monitoring-to-retraining loop. Drift detection on input features and performance drift on the target trigger an automated retrain, but only after the gate evaluation says the retrain will improve things.

Monitoring: three layers, three different problems

Monitoring needs to answer three distinct questions:

Is the system up?, latency, error rate, throughput. Standard SRE metrics. Surfaced in the Model Serving UI and Databricks SQL warehouses.
Has the input distribution shifted?, input drift detection. Lakehouse Monitoring continuously computes statistics on serving requests and compares to baseline. Alerts fire when drift exceeds threshold.
Are the outputs still correct?, quality monitoring. Hard in general because ground truth is delayed or unavailable. Patterns: human review on samples, LLM-as-judge for GenAI workloads, downstream KPI tracking.

Skip layer 1 and you don't know when the service is down. Skip layer 2 and you don't know when the world changed. Skip layer 3 and you don't know when your model started giving worse answers. They are not substitutes for each other.

GenAIOps: classical MLOps with different metrics

The MLOps pattern for LLM-backed systems (RAG, agents) is structurally the same as for classical ML. The metrics change:

Instead of precision/recall, you track answer relevance, faithfulness, groundedness.
Instead of confusion matrices, you track trajectory correctness for agents.
Instead of model files, you version prompts, system messages, and tool definitions.

MLflow Evaluate handles both. The pipeline shape is the same. The deployment story is the same. The discipline is the same. What's different is the failure mode: an LLM system can be wrong in plausible-sounding ways that aren't caught by latency or error-rate monitoring. The fix is to make evaluation a first-class part of the production loop, not a one-time pre-launch activity.

CI/CD pattern that works in 2026

The pipeline pattern most production teams converge on:

Code changes go through pull request.
CI runs unit tests, linting, type checks.
CI deploys the bundle to a staging workspace and runs integration tests.
CI runs the full evaluation suite on a held-out set. Block merge if regression.
On merge to main, CI deploys to production with the new model version as @candidate.
Manual or automated promotion moves @candidate to @production.
Lakehouse Monitoring watches for drift; alerts trigger investigation.

Nothing exotic. The point is having all of it, every time, by default.

What the book covers

The MLOps chapter in Databricks for Practitioners covers:

A reference Asset Bundle for an ML project, end-to-end.
CI/CD pipeline in GitHub Actions and Azure DevOps.
Model Serving with blue-green deployment and rollback.
Lakehouse Monitoring setup with drift alerts.
GenAIOps patterns for RAG and agent workloads.
The governance checklist for audit-grade ML deployments.