How much am I paying for BigQuery time travel and fail-safe?
The invisible storage overhead behind frequently-rewritten tables.
Free to run — INFORMATION_SCHEMA scans no billable bytesChecked 4 Aug 2026
JOBS and TABLE_STORAGE are region-scoped.
SELECT
table_schema,
table_name,
ROUND(active_physical_bytes / POW(1024, 3), 2) AS active_physical_gib,
ROUND(time_travel_physical_bytes / POW(1024, 3), 2) AS time_travel_gib,
ROUND(fail_safe_physical_bytes / POW(1024, 3), 2) AS fail_safe_gib,
ROUND(SAFE_DIVIDE(
time_travel_physical_bytes + fail_safe_physical_bytes,
NULLIF(active_physical_bytes, 0)), 2) AS overhead_ratio
FROM `region-us`.INFORMATION_SCHEMA.TABLE_STORAGE
WHERE NOT deleted
AND time_travel_physical_bytes > 0
ORDER BY time_travel_physical_bytes DESC
LIMIT 100;What it returns
- time_travel_gib
- Previous versions retained for the time-travel window (default 7 days).
- fail_safe_gib
- A further 7 days Google keeps for recovery. You are billed for it and cannot turn it off.
- overhead_ratio
- Overhead ÷ live data. Above 1.0 means you store more history than data.
How to read it
- A high ratio is the signature of WRITE_TRUNCATE on a large table: every full overwrite keeps the old copy for the window.
- The time-travel window is configurable per dataset between 2 and 7 days. Dropping it to 2 on a heavily rewritten staging dataset is a real, immediate saving.
- Fail-safe is not configurable. If the overhead is still unacceptable after tuning time travel, the fix is to stop rewriting the 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.