# SQL Warehouse

> Databricks SQL warehouses bill while running: classic warehouses put DBUs on Databricks and VM hours on your cloud account, while serverless folds compute into a single Databricks-billed rate. Setting auto_stop_mins to 0 disables auto-stop entirely, so ZopNight stops warehouses on schedule and tracks each one's 30-day query activity.

Source: https://zop.dev/integrations/databricks/databricks-sqlwarehouse
Updated: 2026-08-19

---

A SQL warehouse serves BI dashboards and SQL analytics, and it bills while it runs. Its type decides who pays for which half: a classic warehouse bills DBUs to Databricks and VM hours to your cloud account, while a serverless warehouse runs on Databricks-managed compute and folds the machine cost into the Databricks side. Either way, running-while-unused is the waste.

## Serverless moves the VM bill, not the meter

Discovery records the warehouse tier (CLASSIC or PRO), whether serverless compute is enabled, the per-cluster T-shirt size, and the autoscaling cluster bounds, plus live cluster and session counts. Serverless changes whose invoice the machines land on and how fast the warehouse starts. It does not change the fact that a running warehouse bills and a stopped one does not.

## Auto-stop decides the idle bill

`auto_stop_mins` sets how long an idle warehouse keeps billing after its last query, and 0 disables auto-stop entirely. Auto-stop also measures the wrong thing for scheduled traffic: a BI tool refreshing on a timer keeps the warehouse warm around the clock without a human ever opening the dashboard it feeds.

## Thirty days of queries settles arguments

Each warehouse carries a 30-day started-query count and the days since its most recent query, aggregated from workspace query history (whose retention covers the window). A genuine count of 0 marks an orphan candidate. When the history probe fails, the count is omitted rather than zeroed, so a transient API error can never impersonate "never used" and trigger a false orphan finding.

## Scheduled stops wait for confirmation

ZopNight stops a warehouse with a stop-and-wait call and starts it again on schedule, so the schedule window reflects reality rather than a fire-and-forget request. The per-cloud recommendation families cover the advisory side: RC-2200 on Azure, RC-2300 on AWS, RC-2400 on GCP.

## Inspect the fleet

```bash
databricks warehouses list --output json
```

For each warehouse, read `auto_stop_mins`, `state`, and `enable_serverless_compute`. A running warehouse with auto-stop disabled and no recent queries is paying full rate to wait for nobody.