## TL;DR
The agent's validation queries burned the BigQuery quota, usually by scanning full tables for simple checks. Rewrite validations to be cheap: partition filters, metadata queries, sampled counts. Schedule heavy validations off-peak and cap the bytes per query. Validation should sip quota, not gulp it.

```text
bigquery quota exceeded when agent tried validation queries, queries failed
```

## Use this when
- Agent BigQuery validation queries fail on quota exceeded.
- Validations scan large tables fully.
- It happens at peak hours when quota is shared.

## Not for this skill when
- Production queries hit quota. That is a capacity problem.
- Queries fail on syntax. Fix the SQL.

## Steps
1. Check the bytes scanned by the failing validation queries. Note the cost. Verify: the waste is quantified
2. Rewrite the checks cheaply: partition filters, information schema, approximate counts. Note the rewritten queries. Verify: the checks sip quota
3. Set a maximum bytes billed guard on validation queries. Note the guard. Verify: runaway scans are impossible
4. Schedule heavy validations off-peak. Note the schedule. Verify: validations avoid the rush
5. Re-run the validations and confirm they pass under quota. Note the green checks. Verify: validation works sustainably

## Variant phrasings
### bigquery quota validation queries
The use-case search.
### bigquery cheap row count check
The technique phrasing.

Compatibility: BigQuery quotas: concurrent queries, bytes scanned, and slot usage depending on the pricing model.

## Why it happens
BigQuery bills and throttles on usage, and validation queries are the classic unbudgeted consumer: written once, run constantly, scanning everything for a yes-or-no answer. A row count over a petabyte table answers is it fresh with a petabyte of scan. Metadata and partition pruning answer the same question for nearly free. Agents that validate by brute force work until the quota bill arrives; agents that validate cheaply work indefinitely.

## Edge cases / pitfalls
- Approximate counts are fine for freshness and volume checks but not for reconciliation. Match the precision to the question.
- Information schema queries are free but eventually consistent. For just-written data, allow a delay.
- A maximum-bytes guard that is too low fails legitimate checks. Set it from measured check costs, not from zero.
- On-demand versus flat-rate pricing changes which quota bites first. Know your pricing model.

## Provenance

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