Home / Databricks on Azure

Databricks on AzureHow-toIntermediate

Advisory: ML on Azure Databricks or Azure Machine Learning - training, model registry and serving choices

Both Databricks and Azure Machine Learning can train, register and serve models. Decide by where the data and feature pipelines live, who the users are, serving needs and existing MLOps tooling, and avoid splitting one model's lifecycle across both platforms without a clear handover.

Deepak Bhardwaj2 min read

Applies toDatabricks Mosaic AI (MLflow, Unity Catalog models, Model Serving, feature engineering), Azure Machine Learning (workspaces, registries, managed online endpoints), AKS for custom serving

How they compare

Area Databricks Azure Machine Learning
Data and features Close to Delta tables, Unity Catalog feature tables Data assets from many stores; feature store
Training Spark, single-node and GPU clusters, serverless GPU options Compute clusters, GPUs, pipelines, AutoML
Tracking/registry MLflow with models in Unity Catalog MLflow-compatible tracking; AML registries
Serving Model Serving endpoints (CPU/GPU, serverless) Managed online/batch endpoints, AKS
Governance Unity Catalog lineage from data to model Azure RBAC, registries across workspaces
Typical users Data engineers and data scientists already on Databricks ML teams across Azure, broader Azure AI integration

Both evolve quickly; verify current capabilities.

Decision questions

  1. Where do training data and features live? Moving large data for training is costly and slow.
  2. Who builds models and what do they use today?
  3. Serving needs: latency, scale, network isolation, GPU, A/B traffic splitting.
  4. Existing MLOps: CI/CD, approvals, monitoring.
  5. Batch scoring or real-time? Batch scoring next to the data is often simplest on Databricks.

Common patterns

Pattern When
All on Databricks Data, features and teams are on Databricks; serving needs met by Model Serving
Train on Databricks, serve on Azure ML/AKS Org-standard serving platform on Azure ML or AKS; models handed over via MLflow format
All on Azure ML ML teams standardised on AML; data accessed from the lake

For hand-overs, define the contract: model format (MLflow), signature, required features, owner and approval step.

Operational must-haves (either platform)

  • Model registry with versions and stage/alias promotion.
  • Lineage from training data to model.
  • Inference logging and drift/quality monitoring.
  • Rollback to the previous model version.
  • Network isolation and identity for endpoints.

Tip

Avoid running two registries for the same models. Pick one source of truth and let the other platform consume from it.

Checklist

  • Data and feature location considered
  • Users and current tooling assessed
  • Serving requirements documented
  • Pattern chosen with a clear handover contract
  • Single registry of record
  • Monitoring and rollback in place

Related fixes