Databricks support lifecycles

As part of Azure Databricks's commitment to innovation, platform and runtime features might be retired and replaced by new features. Databricks Runtime releases are also retired and replaced on a regular schedule. This page lists retirement phases and details about corresponding support for platform features and Databricks Runtime releases. It also includes SQL queries to detect clusters and jobs using legacy Databricks Runtime versions.

For information about previews and release types, see Azure Databricks preview releases.

Platform feature lifecycle

Azure Databricks platform feature retirement phases are described in the following table:

Phase	Description	Support	Migration notes
Legacy	The feature is still available, but there is a newer, better feature or way to accomplish the tasks that this feature provides. This label is indicative of a future retirement date.	Full. Support and documentation are available.	Migration to a new replacement feature or a new way of accomplishing the task is encouraged, but not immediately necessary.
Deprecated	The feature is no longer in active development. Updates are no longer being released. The feature will soon be retired, so you need to develop a plan to stop using the feature and transition to an alternative.	Full. The feature is no longer being updated, but support and documentation are still available.	Migration to a new replacement feature or a new way of accomplishing the task is highly encouraged, because important updates are no longer being applied.
End of Support (EoS)	The feature is no longer in active development and support is officially unavailable.	None. Documentation might still exist, but it has been archived and is no longer being maintained.	Migration to a new replacement feature or a new way of accomplishing the task is urgent, because important updates are no longer being applied and support for issues that might arise is no longer available.
End of Life (EoL)	The feature has been completely removed from the Databricks product.	None	Migration to a new replacement feature or a new way of accomplishing the task is required, because the feature is no longer usable. At this point it might be very difficult to migrate.

Databricks Runtime support lifecycles

The following tables describe the stages of support and support policies for Databricks Runtime versions. Azure Databricks releases runtimes as Beta and GA versions. Azure Databricks supports GA versions for six months, unless the runtime version is a long-term support (LTS) version. For information on supported Databricks Runtime versions, see Databricks Runtime release notes versions and compatibility.

Workloads on unsupported Databricks Runtime versions might continue to run, but Azure Databricks does not provide support or fixes.

Databricks Runtime LTS version lifecycle

Phase	Description
Beta	Support SLAs are not applicable. For more information, see Databricks Runtime releases.
GA, full support for LTS version	Major stability and security fixes are backported. Databricks releases LTS versions every six months and supports them for three full years. Supported LTS releases are published at Supported Databricks Runtime LTS releases.
End of Support (EoS)	If a version is unsupported: Workloads running on these versions receive no Databricks support. Fixes are not backported. It is no longer selectable using the UI when you create or update a compute resource. The end-of-support date is three years after release. Unsupported releases are published at End-of-support Databricks Runtime release notes.
End of Life (EoL)	Once a version reaches End of Life, it's removed from the Azure Databricks environment and it becomes unusable. You can't launch new workloads, and existing workloads running on these versions fail. You must migrate your workloads to a supported runtime version. Azure Databricks makes a best effort to ensure the end-of-life date is six months following the end-of-support date. However, Databricks reserves the right to completely remove a release version at any time after support ends, without prior notice.

Databricks Runtime Non-LTS version lifecycle

Phase	Description
Beta	Support SLAs are not applicable. For more information, see Databricks Runtime releases.
GA, full support	Major stability and security fixes are backported. Full support for Databricks Runtime versions lasts for six months, with the exception of long-term support (LTS) versions. Supported releases along with their end-of-support dates are published at All supported Databricks Runtime releases.
End of Support (EoS)	If a version is unsupported: Workloads running on these versions receive no Databricks support. Fixes are not backported. It is no longer selectable using the UI when you create or update a compute resource. Unsupported releases are published at End-of-support Databricks Runtime release notes.
End of Life (EoL)	Databricks reserves the right to completely remove a release version at any time after support ends, without prior notice.

Detect which clusters are using legacy Databricks Runtime versions

This temporary view gives a summary of Databricks Runtime cluster usage for clusters running Databricks Runtime versions 10.4 or earlier. It aggregates usage over the past 90 days and includes workspace information, cluster identifiers, Databricks Runtime versions, usage units, and total usage in Databricks Units (DBUs).

CREATE OR REPLACE TEMP VIEW legacy_dbrs AS
WITH clusters_dbr_versions AS (
  SELECT
    account_id,
    workspace_id,
    cluster_id,
    cluster_name,
    owned_by,
    dbr_version,
    TRY_CAST(regexp_extract(dbr_version, '(\\d+)\\.(\\w+)?(?:\\.(\\w+))?', 1) AS INT) AS major_version,
    TRY_CAST(regexp_extract(dbr_version, '(\\d+)\\.(\\w+)?(?:\\.(\\w+))?', 2) AS INT) AS minor_version,
    ROW_NUMBER() OVER(PARTITION BY account_id, workspace_id, cluster_id ORDER BY change_time DESC) AS rnk
  FROM
    system.compute.clusters
  QUALIFY rnk=1
),
usage AS (
  SELECT
    account_id,
    workspace_id,
    usage_metadata.cluster_id AS cluster_id,
    usage_unit,
    ROUND(SUM(usage_quantity), 2) AS total_usage_dbu,
    MAX(usage_date) as last_seen_date
  FROM
    system.billing.usage
  WHERE
    usage_metadata.cluster_id IS NOT NULL AND
    usage_date > CURRENT_DATE() - INTERVAL 90 DAYS
  GROUP BY ALL
),
workspace_info AS (
  SELECT
    account_id,
    workspace_id,
    workspace_name,
    workspace_url
  FROM
    system.access.workspaces_latest
)
SELECT
  cdv.workspace_id,
  wi.workspace_name,
  wi.workspace_url,
  cdv.cluster_name,
  cdv.cluster_id,
  cdv.owned_by,
  cdv.dbr_version,
  total_usage_dbu,
  usage_unit,
  last_seen_date
FROM
  clusters_dbr_versions cdv
    INNER JOIN usage u USING (workspace_id, cluster_id)
    LEFT JOIN workspace_info wi USING (workspace_id)
WHERE
  major_version < 10 OR (major_version = 10 AND minor_version < 4)
GROUP BY ALL
ORDER BY
  workspace_id, total_usage_dbu DESC;

To see legacy Databricks Runtime usage per cluster, query the view that was just created.

SELECT * FROM legacy_dbrs;

To see the aggregated cluster usage across workspaces and Databricks Runtime versions, use the following query. This helps identify which Databricks Runtime versions are still in use, the number of clusters running each version, and the total usage in DBUs.

SELECT
  dbr_version,
  workspace_id,
  COUNT(DISTINCT cluster_id) total_clusters,
  SUM(total_usage_dbu)  AS total_usage_dbu
FROM legacy_dbrs
GROUP BY dbr_version, workspace_id
ORDER BY dbr_version, workspace_id

Detect which jobs are using legacy Databricks Runtime versions

Use this query to retrieve all jobs that have executed in the past 90 days where the most recent run used a Databricks Runtime version earlier than 10.4. This helps identify workloads that require upgrading.

%sql
with latest_jobs AS (
  SELECT
    *,
    ROW_NUMBER() OVER(PARTITION BY workspace_id, job_id ORDER BY change_time DESC) as rn
  FROM system.lakeflow.jobs
  QUALIFY rn=1
),
latest_clusters AS (
  SELECT
    *,
    ROW_NUMBER() OVER(PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) as rn
  FROM system.compute.clusters
  QUALIFY rn=1
),
job_tasks_exploded AS (
  SELECT
    workspace_id,
    job_id,
    EXPLODE(compute_ids) as cluster_id
  FROM system.lakeflow.job_task_run_timeline
  WHERE period_start_time >= CURRENT_DATE() - INTERVAL 90 DAY AND ARRAY_SIZE(compute_ids) > 0
  GROUP BY ALL
),
workspace_info AS (
  SELECT
    account_id,
    workspace_id,
    workspace_name,
    workspace_url
  FROM
    system.access.workspaces_latest
),
clusters_with_dbr AS (
  SELECT
    t1.*,
    t2.cluster_name,
    t2.owned_by,
    t2.dbr_version
  FROM job_tasks_exploded t1
    INNER JOIN latest_clusters t2 USING (workspace_id, cluster_id)
)
SELECT
  wi.account_id,
  wi.workspace_id,
  wi.workspace_name,
  wi.workspace_url,
  latest_jobs.name,
  cwd.job_id,
  cwd.cluster_id,
  cwd.cluster_name,
  cwd.dbr_version
 FROM clusters_with_dbr cwd
 JOIN workspace_info wi ON cwd.workspace_id = wi.workspace_id
 LEFT JOIN latest_jobs USING (workspace_id, job_id)
 WHERE dbr_version RLIKE '^([1-9]\\.|10\\.[0-3]\\.)'

Feedback

Was this page helpful?

Last updated on 2025-11-27