# Oversized Databricks SQL Warehouses | Cloud Efficiency Hub Canonical: 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... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version 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. 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-0521 Type Overprovisioned Resource ## Explanation Why the waste happens and who it affects. The warehouse bills for that size for every minute it runs, whether queries use the capacity or not. When the size is larger than the workload needs, every running hour - including idle time before Auto Stop - costs a multiple of what a smaller warehouse would. Oversizing is common because the default cluster size when creating a warehouse is X-Large, and Databricks' sizing guidance says it is usually more efficient to start with a larger warehouse and size down if necessary, so the size-down step is easy to skip. Size is also raised to fix a slow period or to absorb more concurrent users, when queuing is better handled by adding clusters through scaling. Databricks' cost-optimization best practices advise sizing SQL warehouses on concurrent users and query complexity, starting with Small or Medium and enabling autoscaling. ## Billing model The pricing dimensions that drive this cost. Cluster size Sets the driver instance and worker count per cluster; each step up doubles the workers, and DBU consumption rises with size Running time DBUs accrue per second for as long as the warehouse runs, including idle time until Auto Stop Warehouse type Serverless SQL DBU prices include cloud instance cost; Pro and Classic warehouses also incur cloud instance charges from the cloud provider Scaling Each additional cluster added for concurrency bills at the same size, so size and cluster count multiply ## How to detect 5 checks to find it in your estate. - Join system.billing.usage (billing\_origin\_product = 'SQL', usage\_metadata.warehouse\_id) to the latest system.compute.warehouses record to rank warehouses by DBUs alongside warehouse\_size, warehouse\_type, min\_clusters and max\_clusters - Flag warehouses still at the X\_LARGE default, or at LARGE and above, that serve dashboards, BI tools or ad hoc queries - In system.query.history, filter by compute.warehouse\_id and check spilled\_local\_bytes, execution\_duration\_ms and read\_bytes; Databricks' sizing guidance ties the need for a larger size to queries spilling to disk, so large warehouses whose queries never spill and finish quickly are candidates to size down - Check waiting\_at\_capacity\_duration\_ms and SCALED\_UP events in system.compute.warehouse\_events; if queuing is the problem, it points to more clusters rather than a larger size - Use the query profile for the heaviest statements to confirm that a smaller size would not push them into spilling ## How to fix 5 ways to remove the waste. - Step the cluster size down one level at a time and compare query duration, spill and queue time for a representative period before the next step - Handle concurrency with scaling instead of size: raise max\_clusters for peak concurrency and keep min\_clusters low, since each cluster bills at the full size - Separate heavy SQL ETL or large ad hoc scans from dashboard traffic so dashboards can run on a small warehouse and heavy jobs on a larger one only while they run - Set a smaller size in warehouse templates, Terraform modules or policies so new warehouses do not inherit the X-Large default - Review sizing periodically as dashboards and data volumes change, since a size chosen for a one-time backfill or launch tends to stick ## Documentation Vendor references for pricing and configuration. - [SQL warehouse sizing, scaling, and queuing behavior docs.databricks.com](https://docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior) - [Create a SQL warehouse docs.databricks.com](https://docs.databricks.com/aws/en/compute/sql-warehouse/create) - [Best practices for cost optimization docs.databricks.com](https://docs.databricks.com/aws/en/lakehouse-architecture/cost-optimization/best-practices) - [Query history system table reference docs.databricks.com](https://docs.databricks.com/aws/en/admin/system-tables/query-history) - [Warehouses system table reference docs.databricks.com](https://docs.databricks.com/aws/en/admin/system-tables/warehouses) - [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-0522 ### [Long or Disabled Auto Stop on Databricks SQL Warehouses](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 continue to accumulate DBU and cloud instance charges until they are stopped. For typical use... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.