Databricks SQL warehouse cost: three settings that decide the bill
Databricks SQL warehouse cost depends on size, auto-stop and serverless versus classic more than on query tuning. How each works, and how to set it on evidence.
On most Databricks platforms we look at, the largest single item on the monthly bill is SQL: the warehouses behind dashboards, BI tools and ad hoc queries. And most of what that line costs is decided by three settings that someone chose on the first day and nobody has revisited since.
None of the three requires rewriting a query. They are configuration, and they can be changed in minutes. What they need is evidence about how the warehouse is actually used.
1. Warehouse size: every step roughly doubles the rate
A SQL warehouse comes in named sizes, from 2X-Small to 5X-Large. Databricks publishes what each size is made of, the type of driver machine and the number of workers, rather than a price per hour:
| Size | Workers |
|---|---|
| 2X-Small | 1 |
| X-Small | 2 |
| Small | 4 |
| Medium | 8 |
| Large | 16 |
| X-Large | 32 |
| 2X-Large | 64 |
| 3X-Large | 128 |
| 4X-Large | 256 |
| 5X-Large | 512 |
The pattern is the point: the number of workers doubles at every step, so the cost per hour roughly doubles too. Going up one size is not a few percent more. It is close to twice the rate for every hour the warehouse runs.
Databricks’ own guidance is to start with a larger warehouse and size down, because reducing size is easier than discovering that a small warehouse cannot keep up. That is sensible advice with one condition attached: someone has to actually size down. A warehouse chosen generously for the launch, and never reviewed, pays close to double for the life of the platform.
The way to decide is to look at what the warehouse does. If queries rarely wait and the warehouse spends most of its time under light load, one size smaller is worth trying for a week. If queries queue at peak hours, more capacity may be the answer, but scaling out for the peak is often better than a larger size all day.
2. Auto-stop: an idle warehouse keeps billing
A warehouse is billed for as long as it runs, not for as long as someone uses it. On classic warehouses that means both the Databricks charge and the cloud machines underneath, until the warehouse stops completely.
Auto-stop decides how long a warehouse waits with no queries before it shuts down. The defaults are 45 minutes for pro and classic warehouses and 10 minutes for serverless.
Consider a finance dashboard opened three times a day. Each session ends, and then the warehouse waits. With a 45-minute auto-stop, that is up to two and a quarter hours a day of paid idle time. With 10 minutes, it is half an hour. The difference repeats every working day.
Lowering auto-stop is the cheapest saving on the platform: it takes a minute and changes nothing for users except, occasionally, a short wait for the warehouse to start again. The right value depends on how often queries arrive. A warehouse serving a steady stream of BI traffic can keep a longer window; a warehouse used a few times a day should not.
3. Serverless or classic: where the machines are billed
The third setting is the type of warehouse, and it is the one most often compared the wrong way.
On a classic warehouse, the machines run in your own cloud account. Databricks charges per DBU, and your cloud provider bills the machines separately. On a serverless warehouse, the machines belong to Databricks and are included in the DBU rate. In AWS Singapore in September 2026, SQL Classic was listed at $0.22 per DBU and SQL Serverless at $0.88. The classic figure looks much lower, but it excludes the hardware.
A fair comparison adds the classic DBU cost to the matching cloud bill, and sets that against the serverless DBU cost alone. Beyond price, serverless brings the shorter default auto-stop above and elastic capacity managed by Databricks, and Databricks states that its serverless machines, which may differ from the classic instance types, have comparable price-performance.
For warehouses with uneven use, such as dashboards and ad hoc analysis, serverless often comes out ahead once idle time is counted. For a warehouse under steady, predictable load all day, the comparison deserves real numbers from your own bill before you decide.
A fourth lever that is not a setting
Committing to usage in advance lowers the rate itself. On Azure, pre-purchased Databricks commit units for one or three years are published at up to 37% below pay-as-you-go. On AWS and Google Cloud the discount is negotiated and not published. A commitment only makes sense once usage is measured, which is another reason to fix the three settings first: committing to an oversized, idle warehouse locks in the waste.
Measure before you change anything
Every one of these decisions should be made from data, and Databricks provides it. The system table system.billing.usage records consumption by warehouse and by day, and query history shows how busy each warehouse is and when it sits idle. A few queries on those tables answer the questions above for your own platform, rather than for a hypothetical one.
This is part of what we set up in the Run stage: cost broken down by team and use case, and a review of warehouse size and auto-stop based on measured usage. The rates we use for estimates are on the services page.
Sources: Databricks documentation on SQL warehouse sizing and behaviour (docs.databricks.com/aws/en/compute/sql-warehouse/warehouse-behavior, page last updated 11 September 2026). Databricks pricing pages, AWS AP (Singapore) list rates, read on 16 September 2026. Azure Databricks pricing and pre-purchase terms, read on 16 September 2026. Auto-stop defaults: Databricks documentation on creating a SQL warehouse, read on 16 October 2026. The dashboard example is illustrative.