Explanation
Why the waste happens and who it affects.
The dashboard, model or export that consumed the table was retired or repointed, but the pipeline feeding it was never switched off. The account keeps paying twice: compute for every load and transformation, and storage for a table that grows with each run.
Pipelines are usually owned by data engineering while consumers sit elsewhere, and nobody is notified when the last reader goes away. Snowflake recognizes the pattern directly: its Optimization insights flag large tables that have not been queried in the last week and tables over 100 GB from which data is written but not read. The cost is ongoing rather than one-off, since write activity on permanent tables also keeps generating Time Travel and Fail-safe storage.
Billing model
The pricing dimensions that drive this cost.
- Load and transform compute
- Warehouse credits billed per second while COPY, MERGE, INSERT or task statements run, or serverless charges for Snowpipe and serverless tasks
- Snowpipe ingestion
- Billed per GB of files loaded, 0.0037 Platform Credits per GB in the Snowflake Service Consumption Table
- Table storage
- Flat rate per TB per month by account type and region, covering active data plus Time Travel and Fail-safe history
- Post-drop retention
- A dropped permanent table stays billable through its Time Travel retention period and then 7 days of Fail-safe before storage is released
How to detect
5 checks to find it in your estate.
- Open Snowsight Admin > Cost management > Account Overview and review the Optimization insights 'Large tables that are never queried' and 'Tables over 100 GB from which data is written but not read', which Snowflake refreshes weekly
- For a longer lookback, query SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY (Enterprise Edition or higher) and find tables that appear in OBJECTS_MODIFIED but not in BASE_OBJECTS_ACCESSED or DIRECT_OBJECTS_ACCESSED over 30 to 90 days
- Size each candidate with SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS (ACTIVE_BYTES, TIME_TRAVEL_BYTES, FAILSAFE_BYTES) to rank by storage at stake
- Attribute the write cost by finding the tasks, pipes and service users that load the table in QUERY_HISTORY, TASK_HISTORY and PIPE_USAGE_HISTORY
- Confirm with owners that no consumer outside Snowflake query history depends on the table, such as a share, a replicated secondary or an occasional regulatory export
How to fix
5 ways to remove the waste.
- Stop the feeding pipeline first: suspend the task (ALTER TASK ... SUSPEND), pause the pipe (ALTER PIPE ... SET PIPE_EXECUTION_PAUSED = TRUE), or disable the dbt model or ELT job, so compute stops immediately
- Drop the table (DROP TABLE) once owners agree; it can be restored with UNDROP during its Time Travel period, and storage is released only after Time Travel and 7 days of Fail-safe
- If the data must be kept but not refreshed, keep a final copy and reduce DATA_RETENTION_TIME_IN_DAYS, or unload it to external cloud storage
- For tables that are rebuilt from source on every run, use transient tables, which have no Fail-safe and at most 1 day of Time Travel
- Add a recurring review of write-only tables to data governance, using the Optimization insights or an ACCESS_HISTORY query, and require an owner tag on pipeline targets
Documentation
Vendor references for pricing and configuration.
