What the history can tell you.

How unused tables are identified

We combine a snapshot of your project's tables with collected GCP BigQuery job history. The job's referenced_tables field links query activity to a table. Analysis reads this collected metadata rather than running queries against the contents of your tables.

1. Find the latest observed use.For each table, we take the most recent qualifying job's creation time.
2. Calculate the idle period.Days unused is the number of elapsed whole days since that time. Older activity outside the collected history is not visible.
3. Keep the context.Review the table's query history, the account that ran each query, and the available history before making a decision.

What if there is no query reference?

For a table with no qualifying reference in the collected history, we use the table's creation time to estimate days unused. This is a creation-time fallback, not evidence that the table has never been queried.

Infrequent workloads, missing collection days, recently recreated tables, and stale table snapshots can change how you should interpret a finding.

Views have an observation limit

GCP BigQuery can expand a view into its underlying tables in referenced_tables. A view without a direct qualifying reference therefore has an unknown idle period. We do not substitute the view's creation time or treat missing evidence as proof of inactivity.

Views do not occupy table storage; their estimated storage cost is zero. That says nothing about the cost of queries that use their underlying tables.

How test queries are handled

A routine test can touch a table without representing a production workload. We exclude recognized dbt Labs dbt generic test jobs when computing last use.

A job is recognized only when its SQL contains all three markers: "app": "dbt", a "node_id" starting with "test., and dbt_internal_test. Whitespace variations in the metadata are allowed. Other tests and jobs with missing SQL are not automatically excluded.

Recognized test jobs still appear in the table's recent query history with a test label. If all observed activity is excluded test activity, the creation-time fallback or view limitation above applies.

Your history grows in two stages

After you create a validated connection, the first stage collects table metadata and the most recent 30 days of job history. Once that stage is complete, collection continues toward an initial 180-day history. Collection days use UTC boundaries.

These are collection targets, not a guarantee that every connection already has a complete history. The Dashboard reports collection progress and warns when coverage is still provisional. A successfully collected day with no jobs contributes to coverage; a missing day does not prove zero activity.

Collected history has no automatic expiration while the connection exists, so the observable window can grow over time. See data access and retention.

Cost estimates need context

Unused-table storage estimates use active and long-term logical storage bytes from the collected storage snapshot. The current estimator uses GCP BigQuery asia-east1 monthly logical storage rates divided by 30, including for connections in other regions. It is a reference estimate, and may differ from your region, storage billing model, or bill.

A missing storage snapshot is unknown, not evidence of free storage. Query-cost reports are a separate estimate: eligible standard on-demand scans use billed bytes and the target region's published USD per TiB rate, before free allowances, discounts, and credits. Capacity pricing and unsupported job types are excluded; missing billed bytes or unknown regional prices are not treated as zero.

Neither estimate is an invoice or a guaranteed amount you can save. GCP BigQuery pricing explains the official billing models.

Review before making a change

Check ownership, scheduled or seasonal use, downstream dependencies, and retention requirements. BQ Optimizer does not modify or delete your tables. The decision and any changes remain yours.