The database bill nobody audits

Cloud database spend has a peculiar property: it grows smoothly, so nobody ever has the moment where they look at it and flinch. Each month is a little more than the last, each increase is individually defensible, and eighteen months later the line item is four times what it was with no single decision to point at.

When we audit these bills, the overspend is rarely in the pricing model. It is in a handful of query patterns that were reasonable at small volumes and became expensive at large ones.

1. The query that scans everything to return almost nothing

A report filters on a date range and returns 400 rows. The execution plan shows a full scan of 90 million. Usually the filter is applied to a derived column — WHERE YEAR(created_at) = 2026 — which makes the index unusable. Rewriting to a range predicate on the raw column changes the plan and, on managed platforms billed by data scanned, changes the bill directly.

2. Statistics nobody has refreshed

The optimiser makes its decisions from statistics. When those statistics describe a table as it was two years and forty million rows ago, it will confidently choose a nested loop where a hash join belongs. This is the cheapest fix on this list and the most commonly skipped: a stale-stats problem looks exactly like a hardware problem right up until someone checks.

3. Indexes that exist for queries nobody runs

Every index is paid for twice: once in storage, and again on every write. Estates that have been through several teams accumulate indexes added for a report that was retired long ago. Most engines expose usage counters. Anything unused across a full business cycle — including month-end and year-end, which is why you wait a full cycle — is a candidate for removal.

Adding an index is a five-minute decision that you pay for on every insert, for years.

4. Partitions that are not aligned to how data is queried

Partitioning helps only when the predicate lets the engine skip partitions. A table partitioned by ingest date, queried almost exclusively by transaction date, gets all of the maintenance cost and none of the pruning benefit. This one requires actually reading the query log rather than reasoning about how the table should be used.

5. The pipeline that reprocesses history every night

Full reloads survive because they are simple and correct. They stop being cheap the moment the table is large: reprocessing five years of history nightly to capture one day of change is a cost that grows with your success. Incremental processing with a watermark, plus a scheduled reconciliation to catch drift, keeps the correctness and drops most of the cost.

Where to start

Pull the ten most expensive queries by total cost — not by average runtime, which hides frequently-run cheap-looking queries — and read their plans. In most estates, those ten account for a large majority of the spend, and two or three of them are fixable in an afternoon.

The reason this work is undersold is that it produces no new capability. It just makes the bill smaller and the reports faster, which is a difficult thing to put in a launch announcement and an easy thing to justify to a finance director.