What is my BigQuery cache hit rate, and why is it so low?
Daily cache hit rate plus the bytes that caching saved you.
Free to run — INFORMATION_SCHEMA scans no billable bytesChecked 4 Aug 2026
JOBS and TABLE_STORAGE are region-scoped.
SELECT
DATE(creation_time) AS run_date,
COUNT(*) AS jobs,
COUNTIF(cache_hit) AS cached,
ROUND(COUNTIF(cache_hit) / COUNT(*), 3) AS cache_hit_rate,
ROUND(SUM(total_bytes_billed) / POW(1024, 4), 2) AS tib_billed
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND state = 'DONE'
GROUP BY run_date
ORDER BY run_date;What it returns
- cache_hit_rate
- Fraction of jobs that returned a cached result and cost nothing.
How to read it
- Cached results are free, so a rising hit rate is a falling bill with no other change.
- The cache invalidates when the underlying table changes, so a streaming or frequently-appended table will show near-zero hits no matter what you do.
- Non-deterministic functions in the query text — CURRENT_TIMESTAMP(), RAND(), SESSION_USER() — defeat the cache entirely. So does querying a wildcard table.
Run this once, or have it run every day.
Finitizer evaluates this class of question continuously against your live BigQuery estate, tracks how each number moves between runs, and turns findings into assigned tasks. Read-only and keyless.