# Orphaned SQL Warehouse

> Query count of exactly 0 across 30 days is the sole trigger here: a warehouse nobody queries is clutter whether currently running or stopped, so there is deliberately no power-state filter. ZopNight abstains when the count is absent rather than guess, and attaches no dollar figure.

Source: https://zop.dev/integrations/databricks/recommendations/orphaned-sql-warehouse
Updated: 2026-08-19

---

## Usage decides, not power state

Most of ZopNight's Databricks rules skip stopped resources, since stopped compute is
not current spend. This one deliberately does not: "nobody has queried this warehouse
in a month" is equally true and equally worth knowing whether the warehouse is
currently stopped or, worse, sitting in a running state on a loose auto-stop. That
design choice cuts both ways, and the finding says so: a flagged warehouse may be
actively billing right now, which makes it more urgent, not less accurate.

## One counter, read strictly

The discoverer stamps a 30-day query count onto each SQL warehouse; the rule fires
only when that count is present and exactly 0. An absent counter (older inventory
collected before the field existed) produces no finding, because "we did not measure"
and "nobody queried it" are different statements. No DBU quantity is available to
price the cleanup, so the savings figure is deliberately 0: this is an orphan-hygiene
call, and its dollar consequences depend on what the auto-stop configuration was
doing, which the sibling auto-stop rule prices separately.

## Reproduce it from query history

```bash
databricks api get '/api/2.0/sql/history/queries?filter_by.warehouse_ids=abc123def456&max_results=10'   | jq '.res | length'
```

A result of 0 for a warehouse ID over your chosen window is the raw form of this
finding.

## An age guard that is wired but empty

The rule mirrors its orphan-job sibling with a 30-day minimum-age guard, so a
warehouse provisioned ahead of a launch is spared. But the SQL warehouse API does not
currently expose a creation timestamp, so the guard has nothing to read and is a
no-op today. Practical consequence, stated honestly: a freshly created, not-yet-used
warehouse can appear in this finding. If you know the warehouse is pre-launch
infrastructure, dismiss the finding; the guard will start protecting such cases
automatically once a creation-time producer exists.

## Decommission in the safe order

Repoint first: dashboards, BI connections, and saved queries referencing the
warehouse should move to an active one before anything is turned off. Then stop the
warehouse and tighten its auto-stop as a reversible middle state, and delete only
after a quiet period confirms nothing broke. Deleting first and discovering the
dependent dashboard second is the failure mode this ordering exists to prevent.