The four shapes of warehouse waste

After enough estates, the waste stops being surprising. It arrives in four shapes, in roughly this order of size, and each one needs a different argument before anybody will let you touch it.

One: work nobody consumes

Tables, views and models that are built on a schedule and read by nothing. This is usually the largest single category and the easiest to be wrong about: "nothing reads it" is a claim about every consumer, including the quarterly export somebody runs by hand and the BI tool that queries through a service account. The evidence has to cover the full retention window of the query history, and it has to name what it checked.

Two: work done more often than it is used

A model that rebuilds hourly for a report read daily. A full refresh where an incremental one would do. This is the safest category to act on, because the object stays and only the cadence changes, and it is frequently the fastest saving available. The question to answer is not "how often does this run" but "how stale is the consumer willing to be" — which is a conversation, not a query.

Three: work done inefficiently

Scans that read the whole table to return a week. Joins that explode and then filter. A clustering key chosen before the access pattern existed. These are real engineering changes, they carry real risk, and they need to be proved rather than argued: run the old and the new, compare the output row for row, and show the bytes scanned on both.

Four: capacity you are holding, not using

Warehouses sized for a peak that happens twice a month. Auto-suspend set to ten minutes on a warehouse that gets a query every eleven. Dev and test environments that bill like production. This is the category with the least engineering in it and the most organisational resistance, because somebody sized it that way for a reason they remember and you do not.

The order to attack them in is the reverse of the order they are usually attacked in: capacity first, because it is reversible.