# Long or Disabled Auto Stop on Databricks SQL Warehouses Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/long-or-disabled-auto-stop-on-databricks-sql-warehouses A Databricks SQL warehouse keeps running after its last query until its Auto Stop timer expires, and Databricks states that idle SQL warehouses... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version A Databricks SQL warehouse keeps running after its last query until its Auto Stop timer expires, and Databricks states that idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped. PointFive Research Cloud cost research at PointFive Databricks service [Databricks SQL](https://www.pointfive.co/efficiency-hub/cloud-services/databricks-sql) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0522 Type Inefficient Configuration ## Explanation Why the waste happens and who it affects. For typical use Databricks recommends 45 minutes on Pro and Classic warehouses and 10 minutes on serverless warehouses, the UI defaults. Warehouses set well above those values, or with Auto Stop turned off, pay for long stretches with no running queries. Longer settings usually come from two places. Teams raise the timer, or set it to 0, to avoid the multi-minute start of Pro and Classic warehouses, which Databricks' cost guidance notes leads users to accept the higher cost rather than stop warehouses during idle periods. And warehouses created through the SQL Warehouses API or infrastructure-as-code without an explicit value pick up the API default of 120 minutes rather than the UI default. BI tools that send periodic refresh or keep-alive queries also reset the timer, so a warehouse can stay up all day for a dashboard nobody is looking at. ## Billing model The pricing dimensions that drive this cost. Idle warehouse charges A running warehouse bills DBUs, and for Pro and Classic also cloud instance charges, whether or not queries are running, until it stops Auto Stop Minutes with no running queries before the warehouse stops; 0 disables it Recommended defaults 45 minutes for Pro and Classic (minimum 10) and 10 minutes for serverless (minimum 5 in the UI, as low as 1 via the API) API default Auto\_stop\_mins defaults to 120 minutes in the SQL Warehouses API when not set ## How to detect 5 checks to find it in your estate. - Query the latest record per warehouse in system.compute.warehouses and flag auto\_stop\_minutes = 0, Pro or Classic warehouses above 45, and serverless warehouses above 10 - Flag warehouses whose auto\_stop\_minutes is exactly 120, which usually means they were created by API or Terraform without setting the value - In system.compute.warehouse\_events, measure the time between the last query in system.query.history and the next STOPPING or STOPPED event for each warehouse to estimate idle minutes per day - Group system.query.history by compute.warehouse\_id, client\_application and executed\_by to find BI tools or service principals issuing periodic lightweight queries that keep warehouses from ever reaching Auto Stop - Rank the resulting warehouses by DBUs in system.billing.usage (usage\_metadata.warehouse\_id) to prioritize ## How to fix 5 ways to remove the waste. - Bring Auto Stop back to the recommended defaults or lower (45 minutes or down to 10 on Pro and Classic, 10 or down to 5 on serverless), weighing idle savings against more frequent cold starts - Re-enable Auto Stop on any warehouse set to 0 unless it serves genuinely continuous traffic, and set auto\_stop\_mins explicitly in API calls and Terraform so new warehouses do not inherit the 120-minute default - Move bursty interactive and BI workloads to serverless SQL warehouses, which start in seconds and make short Auto Stop values practical - Reduce or schedule BI tool refreshes and remove keep-alive queries so dashboards do not hold warehouses open outside working hours - For shared Pro or Classic warehouses that must be warm during business hours, keep a short timer and start the warehouse from a scheduled job or the SQL Warehouses API start call before the day begins, rather than a long timer that bills overnight ## Documentation Vendor references for pricing and configuration. - [Create a SQL warehouse docs.databricks.com](https://docs.databricks.com/aws/en/compute/sql-warehouse/create) - [Create a warehouse - SQL Warehouses API docs.databricks.com](https://docs.databricks.com/api/workspace/warehouses/create) - [Best practices for cost optimization docs.databricks.com](https://docs.databricks.com/aws/en/lakehouse-architecture/cost-optimization/best-practices) - [Warehouses system table reference docs.databricks.com](https://docs.databricks.com/aws/en/admin/system-tables/warehouses) - [Warehouse events system table reference docs.databricks.com](https://docs.databricks.com/aws/en/admin/system-tables/warehouse-events) - [Databricks Lakehouse Pricing databricks.com](https://www.databricks.com/product/pricing/databricks-lakehouse) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - Databricks SQL CER-0225 ### [Underuse of Serverless for Short or Interactive Workloads](https://www.pointfive.co/efficiency-hub/inefficiencies/underuse-of-serverless-for-short-or-interactive-workloads) Many organizations continue running short-lived or low-intensity SQL workloads - such as dashboards, exploratory queries, and BI tool integrations - on traditional clusters. This leads to idle compute, overprovisioning, and high baseline... Compute - Databricks SQL CER-0220 ### [Inefficient Query Design in Databricks SQL and Spark Jobs](https://www.pointfive.co/efficiency-hub/inefficiencies/inefficient-query-design-in-databricks-sql-and-spark-jobs) Many Spark and SQL workloads in Databricks suffer from micro-optimization issues - such as unfiltered joins, unnecessary shuffles, missing broadcast joins, and repeated scans of uncached data. These problems increase compute time and... Compute - Databricks SQL CER-0521 ### [Oversized Databricks SQL Warehouses](https://www.pointfive.co/efficiency-hub/inefficiencies/oversized-databricks-sql-warehouses) A Databricks SQL warehouse's cluster size sets the driver instance and the number of workers in each of its clusters, from 2X-Small with one worker up to 5X-Large with 512, doubling at each step. The warehouse bills for that size for every... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.