Data

Your warehouse bill grew faster than your data did.

Snowflake, Databricks and BigQuery costs are almost never a data-volume problem. They're a query, warehouse-sizing and scheduling problem — which makes them an engineering problem with an engineering fix.

FeeFixed, quoted per scope Duration10 business days InputQuery history & usage PlatformsSnowflake · Databricks · BigQuery

Scope

What gets examined

This audit reads your query history. Findings name specific jobs, dashboards and pipelines — not general advice.

The top spending queries and jobs by credit or slot consumption, with the cost of each attributed to a team or dashboard
Warehouse and cluster sizing against actual concurrency, including anything scaled up during an incident and never scaled back
Auto-suspend and auto-resume settings — idle compute is the single most common finding
Scheduled jobs that run hourly to serve a dashboard somebody opens once a month
Full-table scans that clustering, partitioning or a materialised view would eliminate
Development and test environments running production-sized compute
Storage retention and time-travel windows set once at defaults and never revisited
Reverse ETL and BI tool query patterns hitting the warehouse far more often than the data changes

Deliverable

What you get on day fourteen

A cost-attributed query list. The top consumers ranked by spend, each mapped to the team, dashboard or pipeline responsible. This tends to change the conversation immediately, because the cost stops being abstract.

Specific rewrites and configuration changes, with the expected saving and the effort for each. Where a fix needs a data engineer rather than a config toggle, that's stated.

A guardrail proposal — resource monitors, query timeouts, warehouse policies — so the saving holds instead of drifting back over two quarters.

Fit

When this is worth it

Worth it if your data platform bill is over about $10,000 a month, has grown noticeably faster than your data volume or headcount, and no one can explain why. Also worth it right after a platform migration, when defaults tend to be left in place.

Not worth it if you have a dedicated data platform engineer already tracking cost per query. They'll find the same things and know your schema better than we will.

Questions

The ones we get asked first

What access do you need?

Read access to query history and usage views — Snowflake's ACCOUNT_USAGE, Databricks system tables, or BigQuery INFORMATION_SCHEMA. No access to the data itself is required, and we'd rather not have it.

Do you need to see our actual data?

No. The audit reads metadata about queries, not query results. If your platform allows it, we'll take a role that can't read table contents at all.

We're already on a capacity commitment. Does that change anything?

It changes the shape of the saving, not whether there is one. Reducing consumption under a commitment means you either avoid overage or right-size the next commitment. Both are real money, just realised on different dates.

Will this break our dashboards?

Nothing changes during the audit — it's read-only. Every recommendation states the risk, and anything that alters query results is flagged separately from pure cost changes.

Also available

The other audits

Cloud infrastructureCommitments, idle resources, storage and network SaaS & licensingInactive seats, duplicate tools, wrong tiers ObservabilityMetric cardinality, log volume, retention Contracts & vendorsRenewal exposure, licensing position, evidence Essential EightScored maturity assessment and costed roadmap

Next step

What's your warehouse costing this month?

If it's more than last month and nobody knows why, that's exactly the situation this audit is built for.

Start a conversation