Workspace Model Registry on Databricks


This documentation covers the Workspace Model Registry. Databricks recommends using Models in Unity Catalog. Models in Unity Catalog provides centralized model governance, cross-workspace access, lineage, and deployment. Workspace Model Registry will be deprecated in the future.

MLflow Model Registry is a centralized model repository and a UI and set of APIs that enable you to manage the full lifecycle of MLflow Models. Model Registry provides:

  • Chronological model lineage (which MLflow experiment and run produced the model at a given time).

  • Model Serving.

  • Model versioning.

  • Stage transitions (for example, from staging to production or archived).

  • Webhooks so you can automatically trigger actions based on registry events.

  • Email notifications of model events.

You can also create and view model descriptions and leave comments.

You can work with the model registry using either the Model Registry UI or the Model Registry API. This page presents conceptual information and also includes an example notebook illustrating what you can do with the Model Registry.

For instructions on how to use the Model Registry to manage the model lifecycle in Databricks, see Manage model lifecycle using the Workspace Model Registry.

Model Registry concepts

  • Model: An MLflow Model logged from an experiment or run that is logged with one of the model flavor’s mlflow.<model-flavor>.log_model methods. Once logged, you can register the model with the Model Registry.

  • Registered model: An MLflow Model that has been registered with the Model Registry. The registered model has a unique name, versions, model lineage, and other metadata.

  • Model version: A version of a registered model. When a new model is added to the Model Registry, it is added as Version 1. Each model registered to the same model name increments the version number.

  • Model stage: A model version can be assigned one or more stages. MLflow provides predefined stages for the common use-cases None, Staging, Production, and Archived. With the appropriate permission you can transition a model version between stages or you can request a model stage transition.

  • Description: You can annotate a model’s intent, including description and any relevant information useful for the team such as algorithm description, dataset employed, or methodology.

  • Activities: Each registered model’s activities—such as request for stage transition—is recorded. The trace of activities provides lineage and auditability of the model’s evolution, from experimentation to staged versions to production.

Registered models page

The registered models page displays when you click Models Icon Models in the sidebar. This page shows all of the models in the registry.

You can create a new model from this page.

Also from this page, workspace administrators can set permissions for all models in the model registry.

Registered models

Registered model page

To display the registered model page for a model, click a model name in the registered models page. The registered model page shows information about the selected model and a table with information about each version of the model.

From this page, you can also:

Model version page

To view the model version page, do one of the following:

  • Click a version name in the Latest Version column on the registered models page.

  • Click a version name in the Version column in the registered model page.

This page displays information about a specific version of a registered model and also provides a link to the source run (the version of the notebook that was run to create the model). From this page, you can also:

Model version


For an example that illustrates how to use the Model Registry to build a machine learning application that forecasts the daily power output of a wind farm, see: