SQL Warehouse
Does ZopNight manage 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.
Rules that fire on SQL Warehouse
At a glance
| Field | Value |
|---|---|
| Scheduling notes | issues a warehouse Stop (StopAndWait) and starts it again on schedule |
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
databricks warehouses list --output jsonFor 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.