# Missing Table Expiration on Temporary BigQuery Tables Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/missing-table-expiration-on-temporary-bigquery-tables BigQuery tables never expire unless an expiration is set. Google's documentation is explicit: if no default table expiration is set on the dataset and... By: PointFive Updated: 2026-09-28 [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) The short version BigQuery tables never expire unless an expiration is set. PointFive Research Cloud cost research at PointFive GCP service [GCP BigQuery](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-bigquery) Category [Databases](https://www.pointfive.co/efficiency-hub/service-category/databases) Reference CER-0487 Type Excessive Data Retention ## Explanation Why the waste happens and who it affects. Google's documentation is explicit: if no default table expiration is set on the dataset and no expiration is set on the table when it is created, the table never expires and must be deleted manually. Scratch tables from ad hoc analysis, intermediate tables written by ELT pipelines, staging copies from loads and large query-result destination tables therefore stay in storage, and keep billing, long after the job that produced them has finished. In shared analytics projects many people and tools create tables and few delete them. Because each table is small relative to the total, the growth goes unnoticed. BigQuery's cost best practices recommend using the default table expiration time on destination tables for large query results so the data is removed automatically when no longer needed. ## Billing model The pricing dimensions that drive this cost. Temporary tables are billed like any other BigQuery storage. Active storage Tables or partitions modified in the last 90 days are billed at the active storage rate per GiB, on the dataset's logical or physical billing model Long-term storage Tables or partitions not modified for 90 consecutive days drop to roughly half the price but are still billed Table expiration A table with an expiration time is deleted automatically, with its data, when the time is reached Time travel and fail-safe Deleted or expired data remains recoverable for the time travel window (2 to 7 days) plus fail-safe, and on physical billing those bytes are billed ## How to detect 5 checks to find it in your estate. - Query INFORMATION\_SCHEMA.TABLE\_STORAGE for large tables in datasets used for scratch, staging, sandbox or temporary data, using total\_logical\_bytes or total\_physical\_bytes with creation\_time and storage\_last\_modified\_time - Query INFORMATION\_SCHEMA.TABLE\_OPTIONS for tables with no expiration\_timestamp, and check dataset metadata for datasets with no default table expiration - Find tables not read recently by joining TABLE\_STORAGE with INFORMATION\_SCHEMA.JOBS referenced\_tables over the last 30 to 90 days - Look for naming patterns such as tmp\_, temp\_, scratch\_, staging\_ or date-suffixed copies that are older than the pipelines that create them - Identify scheduled queries and pipelines that write destination tables without setting an expiration ## How to fix 5 ways to remove the waste. - Set a default table expiration on scratch, staging and sandbox datasets (in days in the console, seconds in bq, milliseconds in the API); new tables inherit it unless they set their own - Apply expiration to tables that already exist, because changing a dataset's default does not affect existing tables: set expiration\_timestamp with ALTER TABLE SET OPTIONS or bq update, or delete tables that are no longer needed - Have pipelines set an expiration on intermediate and destination tables when they create them, or drop them at the end of the run - For partitioned tables that only need recent data, use a partition expiration so old partitions are removed automatically - Before expiring data that must be retained for audit or compliance, export it to Cloud Storage in an appropriate storage class ## Documentation Vendor references for pricing and configuration. - [Estimate and control costs docs.cloud.google.com](https://docs.cloud.google.com/bigquery/docs/best-practices-costs) - [Update dataset properties docs.cloud.google.com](https://docs.cloud.google.com/bigquery/docs/updating-datasets) - [Manage tables docs.cloud.google.com](https://docs.cloud.google.com/bigquery/docs/managing-tables) - [TABLE\_STORAGE view docs.cloud.google.com](https://docs.cloud.google.com/bigquery/docs/information-schema-table-storage) - [BigQuery pricing cloud.google.com](https://cloud.google.com/bigquery/pricing) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP BigQuery CER-0295 ### [Overselecting Data and Misusing LIMIT for Cost Control in BigQuery](https://www.pointfive.co/efficiency-hub/inefficiencies/overselecting-data-and-misusing-limit-for-cost-control-in-bigquery) Analysts use SELECT \* (reading more columns than needed) and/or rely on LIMIT as a cost-control mechanism. In BigQuery, projecting excess columns increases the amount of data read and can materially raise query cost, particularly on wide... Databases - GCP BigQuery CER-0226 ### [Unoptimized Billing Model for BigQuery Dataset Storage](https://www.pointfive.co/efficiency-hub/inefficiencies/unoptimized-billing-model-for-bigquery-dataset-storage) Highly compressible datasets, such as those with repeated string fields, nested structures, or uniform rows, can benefit significantly from physical storage billing. Yet most datasets remain on logical storage by default, even when... Databases - GCP BigQuery CER-0069 ### [Inefficient Use of Reservations in BigQuery](https://www.pointfive.co/efficiency-hub/inefficiencies/inefficient-use-of-reservations-in-bigquery) Teams often adopt capacity-based pricing (BigQuery editions reservations with baseline slots and optional commitments) to stabilize costs or optimize for heavy, recurring workloads. However, if query volumes drop - due to seasonal cycles,... Databases --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.