An experiment ends. A dashboard moves. A pipeline gets replaced. The old destination remains, sometimes with a scheduled job still writing to it. Months later, someone sorts the storage inventory by size and asks a reasonable question: can we delete this?
The answer requires more than a quiet usage chart. An unreferenced BigQuery table is a candidate for investigation. It is not automatically a deletion candidate.
The useful goal is a documented decision: keep it for a known purpose, change its lifecycle, or retire it with evidence and approval. This guide explains how to get there.
- Define the projects, regions, access paths and observation period covered by your evidence.
- Inspect readers, writers and downstream dependencies; a table can be actively maintained without serving a current consumer.
- Confirm a business owner and retention purpose before changing the lifecycle.
- Estimate removable cost using the relevant storage billing model, rather than multiplying displayed size by a generic rate.
- Separate approval to retire a table from verification that the intended cost and operational outcomes occurred.
What does “unused” actually mean in BigQuery?
“Unused” is often shorthand for several different observations. Each supports a different next step.
| Observation | What it establishes | What to investigate next |
|---|---|---|
| No read found in the evidence reviewed | No observed read within that scope | Coverage gaps and infrequent consumers |
| Regular writes but no observed reads | A producer is maintaining the object | Whether the output still serves a purpose |
| No identifiable owner | Accountability is unresolved | Team, service and pipeline ownership |
| A similar table exists elsewhere | There may be overlapping datasets | Differences in content, access and purpose |
| A large storage footprint | The object deserves a cost review | Billable storage and removable cost |
A useful finding therefore says: “No observed reads in the reviewed projects and period; owner confirmation pending.” That wording communicates both evidence and uncertainty. “Unused, safe to delete” hides the decision that still needs to happen.
1. Establish what your evidence can actually see
Google documents a 180-day history for the BigQuery JOBS view. Its referenced_tables field is populated for query jobs that are not cache hits, and the view is scoped by project and region. These boundaries matter when investigating a negative finding.
Before reviewing individual tables, write down which execution projects and locations you collected. The project storing a dataset may not be the only project from which consumers submit jobs. Review other access paths and operational records where relevant, rather than assuming query history covers every use.
The observation period should also match the business rhythm. A monthly finance table and an annual reconciliation table do not have the same expected access pattern. A quiet thirty-day period might be meaningful for one and almost irrelevant for the other.
Use the evidence to describe what you observed, then ask whether the coverage is sufficient for the proposed change. A missing event does not explain whether the event was unnecessary, outside the window, or outside your visibility.
A cleanup decision requires evidence coverage, dependency context and owner approval.
2. Follow the producer as well as the consumer
Storage review often starts at the table and stops at the last known read. A better investigation also looks upstream.
What creates this table? What refreshes it? Does another process recreate it after deletion? Does its producer also maintain outputs that remain essential?
Imagine an obsolete sales dashboard whose daily preparation job still runs. Deleting the output without reviewing the producer may lead to recreation, repeated failures or an operational incident. Conversely, disabling a shared producer because one destination is obsolete could interrupt other consumers.
Record the table, the producing job, known downstream dependencies and the proposed scope of change together. If the evidence identifies only the output, the investigation is incomplete.
Lineage helps answer where the object fits. Business context answers why that relationship still matters. Neither should be inferred solely from a table name such as temp, backup or old.
3. Resolve ownership before asking for approval
A service account can identify a useful lead without identifying the person authorized to retire a dataset.
The review needs someone who can confirm the table’s purpose, consult its consumers and approve a lifecycle decision. That may involve a data product owner and a platform team, with additional review for records governed by retention requirements.
Ask three concrete questions:
- What business process would fail or become harder if this object were unavailable?
- Who can confirm that the process has ended or moved elsewhere?
- What evidence would make the retirement decision acceptable to that owner?
If nobody can answer, assign an ownership-resolution task with a review date. Leaving the table unchanged temporarily is reasonable. Letting “unknown owner” become a permanent exemption is how cleanup backlogs turn into recurring costs.
4. Choose a lifecycle action, not just a delete command
There are several useful outcomes from a storage investigation.
| Decision | Appropriate circumstance | Evidence to retain |
|---|---|---|
| Keep | A current business or recovery purpose is confirmed | Purpose, owner and next review date |
| Adjust retention | The object is needed, but its lifecycle exceeds the requirement | Approved retention requirement and impact review |
| Retire a producer and its output | Both are obsolete and dependencies have been checked | Consumer confirmation and coordinated change plan |
| Consolidate | Overlapping objects can be replaced by an approved shared source | Equivalence checks and consumer migration plan |
| Investigate further | Ownership or coverage remains incomplete | Missing evidence, responsible person and deadline |
Retaining a snapshot or archived copy can be appropriate, but it is a new lifecycle decision with its own access, cost and recovery implications. Moving the same uncertainty elsewhere does not close the original finding.
Avoid experimenting with production dependencies by renaming or deleting the object and waiting for someone to complain. The review should establish the decision before the destructive action.
5. Estimate the cost that can actually disappear
A storage inventory is not a savings ledger.
BigQuery’s TABLE_STORAGE documentation notes that clone and snapshot byte values can look like complete tables rather than their incremental storage. Summing those displayed sizes can therefore overstate their billable footprint. The documentation also distinguishes a point-in-time byte count from storage billed over time.
Retention matters too. With physical storage billing, time travel and fail-safe storage are billed separately; with logical storage billing, these are included in the base storage rate. A deletion can therefore have a different cost trajectory depending on the model. See Google’s guidance on data retention with time travel and fail-safe.
Build a modest, explainable estimate: the relevant billable storage, the applicable rates, the expected timing and any retained replacement copy. Keep possible compute savings from retiring the producer separate from storage savings. Include investigation or migration effort when comparing the opportunity with other work.
This approach may produce a smaller estimate than “table size multiplied by price.” It produces a decision that finance and engineering can both understand.
A worked example: the retired reporting table
Consider a hypothetical table called campaign_summary_legacy.
The first review finds no recent consumer query in the collected evidence. A nightly producer still writes to the table. A similarly named replacement exists, but the owner has not confirmed that all consumers migrated.
Initial decision: investigate. There is a plausible opportunity, but no approved retirement yet.
The marketing analytics owner then confirms that the previous dashboard has been retired. The team checks the relevant consumer projects, reporting schedule and repository configuration. No remaining requirement is identified within the agreed review scope. The owner approves a coordinated change to the obsolete producer and output, with an agreed recovery approach.
Delivery decision: retire through the normal change process.
After deployment, the team checks that the job no longer recreates the table, remaining reporting still works, and the expected storage changes appear. Financial verification happens against the relevant billing period, allowing for retention and reporting timing.
Closure: the team records what changed, who approved it, which checks passed and what cost outcome was observed. Any estimate still awaiting billing evidence remains an estimate.
This is an illustrative workflow, not an Anavsan customer result.
Where Anavsan’s BigQuery lineage fits
Anavsan’s BigQuery dataset lineage connects job-level table references, destinations and identity signals to workload ownership. Where ownership cannot be resolved, a finding remains “needs owner.” The product complements Google’s lineage capabilities rather than replacing its catalog. Changes follow the team’s review process; Anavsan does not automatically apply them.
For a storage review, the operating discipline is Trace → Assign → Enforce → Prove: establish the context, resolve responsibility, carry an approved decision through delivery, and check its outcome.
The technical finding starts the conversation. The owner and the evidence determine the action.
A cleanup record your team can reuse
Before approving a lifecycle change, capture these fields in the same work item:
- Object: fully qualified table and producing workload.
- Coverage: projects, locations, access paths and dates reviewed.
- Purpose: current consumers and business or retention requirement.
- Owner: decision-maker and delivery owner.
- Change: keep, adjust, consolidate or retire, with rationale.
- Recovery: agreed approach, limitations and responsible person.
- Economics: estimated removable storage and compute cost, separately.
- Proof: operational checks, billing comparison and review date.
You do not need a perfect organization-wide catalog to improve the next decision. You need to be explicit about the evidence you have and the evidence still missing.
Start with one unreferenced table. Can your team explain who owns it, why it exists and what would prove that retiring it helped? Explore Anavsan’s BigQuery dataset lineage.
Frequently asked questions
Continue reading
- Snowflake Data Lineage: See Connections, Check Usage with Anavsan — the companion investigation pattern for unused Snowflake objects
- BigQuery Cost Optimization: How Workload Drift Brings Costs Back — why one-time cleanup does not stay closed without ownership
- Your Cloud Bill Dropped. Did You Actually Save Money? — how to separate an approved change from verified savings
- BigQuery Storage Intelligence — logical vs physical billing, time travel and fail-safe in product context
- BigQuery Dataset Lineage
Sources
Technical references reviewed November 2, 2026. Workflow recommendations and the worked scenario are editorial guidance.