# Outdated Databricks Runtime Versions on Classic Compute Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/outdated-databricks-runtime-versions-on-classic-compute Every classic Databricks cluster, job cluster and pipeline runs a specific Databricks Runtime (DBR) version chosen when the compute is defined. By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version Every classic Databricks cluster, job cluster and pipeline runs a specific Databricks Runtime (DBR) version chosen when the compute is defined. PointFive Research Cloud cost research at PointFive Databricks service [Databricks Compute](https://www.pointfive.co/efficiency-hub/cloud-services/databricks-compute) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0530 Type Outdated Version ## Explanation Why the waste happens and who it affects. Databricks releases runtimes on a regular cadence, and its cost-optimization best practices note that these releases bring performance improvements that often reduce cost through more efficient use of compute. Workloads left on old runtimes do the same work with an older engine and optimizer, so they can run longer and consume more DBUs and cloud instance hours than they would on a current version. Runtime versions are pinned by default: the spark\_version in a job definition, cluster JSON, Terraform module or compute policy stays fixed until someone edits it, and even the auto:latest-lts policy value does not update existing compute when a new runtime ships. Teams avoid upgrades because of library and API changes, so jobs stay on versions that are several releases behind or near end of support. Beyond cost, versions past end of support receive no fixes, and at end of life existing workloads on them fail, which forces a rushed migration. ## Billing model The pricing dimensions that drive this cost. DBU consumption Classic compute is billed in DBUs at per-second granularity for as long as the cluster runs, at a rate set by the compute type and instance size Cloud instance charges The virtual machines behind classic compute are billed separately by the cloud provider for the same running time Runtime-driven duration The runtime version itself has no separate price, but a slower engine lengthens run time, which raises both DBU and instance charges ## How to detect 4 checks to find it in your estate. - Query system.compute.clusters for the latest record of each non-deleted cluster (delete\_time is null) and group by dbr\_version and cluster\_source to find all-purpose, job and pipeline compute on older runtimes - Compare those versions against the Databricks Runtime release notes and support lifecycle page, flagging versions that are several releases behind the latest LTS or close to end of support - Join system.compute.clusters to system.billing.usage on usage\_metadata.cluster\_id to rank outdated-runtime compute by DBUs consumed, so upgrades start with the most expensive workloads - Review job definitions (Jobs API or asset bundles) and Terraform modules for hard-coded spark\_version values, and compute policies whose spark\_version is fixed to an old runtime ## How to fix 4 ways to remove the waste. - Upgrade high-cost workloads to the latest LTS runtime in a test run first, and compare run duration and DBUs from system.billing.usage before and after; test library compatibility and review the runtime migration notes for behavior changes - Update compute policies to allow only supported recent runtimes, using an allowlist or regex on spark\_version or special values such as auto:latest-lts, so new compute does not start on old versions - Remember that policy special values do not auto-update existing compute; schedule a periodic sweep that bumps pinned spark\_version values in jobs, bundles and Terraform - Where workloads fit, move them to serverless compute, where the runtime is managed by Databricks rather than pinned per cluster ## Documentation Vendor references for pricing and configuration. - [Best practices for cost optimization docs.databricks.com](https://docs.databricks.com/aws/en/lakehouse-architecture/cost-optimization/best-practices) - [Databricks support lifecycles docs.databricks.com](https://docs.databricks.com/aws/en/release-notes/runtime/databricks-runtime-ver) - [Compute system tables reference docs.databricks.com](https://docs.databricks.com/aws/en/admin/system-tables/compute) - [Compute policy reference docs.databricks.com](https://docs.databricks.com/aws/en/admin/clusters/policy-definition) - [Databricks Pricing databricks.com](https://www.databricks.com/product/pricing) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - Databricks Compute CER-0189 ### [Lack of Workload-Specific Cluster Segmentation](https://www.pointfive.co/efficiency-hub/inefficiencies/lack-of-workload-specific-cluster-segmentation) Running varied workload types (e.g., ETL pipelines, ML training, SQL dashboards) on the same cluster introduces inefficiencies. Each workload has different runtime characteristics, scaling needs, and performance sensitivities. When mixed... Compute - Databricks Compute CER-0222 ### [Poorly Configured Autoscaling on Databricks Clusters](https://www.pointfive.co/efficiency-hub/inefficiencies/poorly-configured-autoscaling-on-databricks-clusters) Autoscaling is a core mechanism for aligning compute supply with workload demand, yet it's often underutilized or misconfigured. In older clusters or ad-hoc environments, autoscaling may be disabled by default or set with tight min/max... Compute - Databricks Compute CER-0195 ### [Overuse of Photon in Non-Production Workloads](https://www.pointfive.co/efficiency-hub/inefficiencies/overuse-of-photon-in-non-production-workloads) Photon is frequently enabled by default across Databricks workspaces, including for development, testing, and low-concurrency workloads. In these non-production contexts, job runtimes are typically shorter, SLAs are relaxed or nonexistent,... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.