3 August 2026
A corporate data platform running at $262,887/year on Snowflake. Three weeks, read-only access to the account usage views, no changes to their data model. Here is the entire register — including the things we checked and found healthy, and the two conclusions we had to retract.
Identifiers are generalised throughout. The numbers are not.
| Tier | $/year | % of run rate |
|---|---|---|
| Committed — config only, no change window | $20,318 | 7.7% |
| Probable — adds two decisions | $48,552 | 18.5% |
| Probable + contract renegotiation | $74,841–101,129 | 28–38% |
The committed tier is the number we would defend in front of a CFO without further work. It needed six configuration changes and one bug report. No code changes, no application changes, no change window.
The container platform showed a flat 24/7 profile, which initially looked like 122 permanently resident services. It wasn't: 115 of the 122 were suspended correctly. Only seven were running, and six of those were personal dashboard apps in individual scratch databases.
The cause was a single parameter. Those services carried an auto-suspend of 259,200 seconds — three days. An app opened once on Monday stayed resident all week, holding six nodes at roughly 0.85 credits/hour.
Dropping auto-suspend to an hour models out at a 58% reduction in node-hours against a 50-hour working week. We quoted 50%, about $7,215/yr, because a minimum node count sets a floor. The cost is a 30–60 second cold start on reopen — fine for sandbox apps, not fine for anything customer-facing, which is worth confirming before touching it.
The staging layer held 34.95 TB, of which 18.45 TB had not been written in over 90 days — the oldest untouched for 424 days. Nearly 9,900 tables in it sat at 90-day retention.
Staging data is reloadable by definition. Ninety days of time travel on it protects nothing you couldn't rebuild from source. Confirm reloadability with the owner and it's two changes.
Ninety-seven databases sat at 1-day retention. Twenty-one created after a certain date carried 90 days. Someone had changed the provisioning template and nobody had noticed.
The cost today is small, which is exactly why it's worth reporting. Those are the highest-churn databases in the estate — one holds over 25,000 tables — so at 90-day retention they accumulate quietly for the next quarter. Catching a regression early is a much easier internal sale than reclaiming waste that has already piled up.
One warehouse showed the classic serial-small-query pattern. We priced the fix at 70% of its $20,252 annual cost, which is an industry norm, not something we measured in this account — and the register says so on the row. It also requires a data science team to change their code, which is why it sits in Probable rather than Committed.
Priced on the assumption of scoping to the top 50 users, who drove roughly 75% of usage. A budget decision rather than an engineering one.
The largest single item on the engagement and the only perishable one: consumption was running at 2.4× the commitment, and the term had a fixed end date. Everything else on this list can be done next quarter. This one couldn't.
This section is not filler. A review that only lists problems gives you no way to know where not to spend next quarter.
We told the client storage was clean. Then we retracted it. Then we retracted the retraction.
The first pass found $2,386 of reclaimable storage against a $30,017 line and we called it a clean negative. The second pass showed 52% of storage spend wasn't in active tables at all. We theorised dropped tables, quantified it, and were wrong. We theorised dropped databases, quantified it, and were wrong again.
The actual error was methodological and the same all three times: we were using a table-detail view to compute account totals. The table view under-reported by 51.2 TB. Once we reconciled against the database-level history, measured storage came to 133.43 TB against 137.83 TB billed — a 4.4 TB residual that is stage storage and daily-average timing.
Only then did the real finding appear: the staging database above, worth $5,822/yr. We would have missed it entirely by stopping at "storage is fine."
That is now a hard gate in our own checklist: reconcile storage against account totals before any table-level analysis, and don't call anything clean until the reconciliation closes.
Everything above is derived from billed dollars, not credits multiplied by an assumed rate. Rate assumptions are how cost estimates end up 40% wrong; an earlier version of this register swung by exactly that much before we re-based it on the invoice.
Cloud services costs of $8,992/yr were deliberately excluded from the totals. They are largely generated by the same runaway query loop and write pattern counted elsewhere, and including them would double-count the same fix.
One open question went to the client unanswered, because it wasn't a finding yet: the preparation layer is 2.5× the size of the presentation layer it feeds. Probably legitimate. Nobody had asked.
If you're spending $200k or more a year on Snowflake and can't say which six configuration changes are worth the most, that's the engagement.