## TL;DR
A validation that reads the whole table to answer a small question, how many rows landed, are the keys unique, is like weighing a truck to check its cargo arrived. On Snowflake that scan runs on a warehouse that bills by size and time, and an agent repeating it per table per run can spike credits and even look like a runaway workload. Validate from metadata and samples instead: table row counts from information views, uniqueness on a hash sample or on the new window only, and freshness from the load ledger, with a small warehouse and a query timeout set for validation work.

```text
agent's validation query spiked snowflake credits, warehouse auto-suspended
```

## Use this when
- Snowflake credit usage spikes at the same times an agent validates loads.
- The warehouse shows long full scans from validation style queries in the query history.
- Validation queries run against the largest tables in full, repeatedly.

## Not for this skill when
- The production transformation queries are the expensive ones in the query history. Optimise those, validation is a bystander.
- A one off deep audit genuinely needs full scans. Schedule and budget it as an audit, not a per run check.

## Steps
1. In Snowflake query history, find the validation queries by their text and the agent's user or role, and note their credits, bytes scanned, and run frequency. Note the worst offenders. Verify: the cost is attributed to specific queries with numbers
2. For each offender, state the question it answers in one sentence, then find the cheapest source for that answer: metadata row counts, the load ledger, a partition or window scoped query, or a sampled check. Note the replacement per query. Verify: each validation keeps its question and loses its scan
3. Scope the checks that must touch data to the newly loaded window using the load timestamp or partition key, so their cost tracks the increment, not the table's history. Note the window predicate. Verify: validation cost grows with the load, not with the table
4. Run validations on a small dedicated warehouse with auto-suspend set aggressively and a statement timeout, so a runaway check dies cheaply and alone. Note the warehouse and timeout settings. Verify: a bad validation cannot burn the main warehouse again
5. Add a cost guard to the agent: record bytes scanned or credits per validation run and stop and report if it exceeds a set budget. Rerun a full load validation and note the new cost. Note the before and after figures. Verify: cost is measured per run and the fix is quantified

## Variant phrasings
### snowflake validation count query full table scan credits expensive
The full scan phrasing.
### cheap data validation snowflake metadata row count sample
The cheap alternatives searched directly.

Compatibility: Snowflake warehouses with query history and account usage views, any agent or dbt style validation running SQL checks. Metadata based counts are exact for whole tables on Snowflake; sampled checks are estimates by design.

## Why it happens
Validation questions are usually about the increment, but the natural way to write them is about the table, and the gap between those two is the entire history of the data, scanned fresh on every run. Agents write the table version because it is simpler and always correct, and nothing in the feedback loop tells them it cost real money: the query succeeds, the answer is right, the bill arrives later, aggregated with everything else. Scoping checks to the increment and pricing them per run aligns the agent's incentives with the platform's cost model.

## Edge cases / pitfalls
- A uniqueness check scoped to the new window misses duplicates against old data. Pair a cheap old versus new key overlap check on hashed keys for that case rather than scanning both sides in full.
- Metadata row counts can lag or reflect the table, not the partition you loaded. Confirm the metadata source answers the window question before trusting it.
- Auto-suspend is a billing protection with a resume cost. A warehouse suspending mid validation burst adds latency that can look like flakiness.
- Statement timeouts kill the symptom and can hide a check that never completes. Alert on validation timeouts as failures, not as savings.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zB3AeLJ4sfVTFz9LfWZM4Q