At a glance
The single biggest table in your account by total physical storage, reported in gigabytes. Storage in Snowflake is cost-anchored: the tables at the top of this list are the ones quietly driving your monthly storage bill, so knowing your number one is the first step to deciding what to prune, partition, or move to a cheaper retention policy. It is a live capacity signal for the platform team, not a performance metric.
What it tracks
The card readsSNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS and surfaces the table with the highest total storage footprint. “Total” here means more than just live rows: Snowflake’s TABLE_STORAGE_METRICS reports ACTIVE_BYTES (current data), TIME_TRAVEL_BYTES, FAILSAFE_BYTES, and RETAINED_FOR_CLONE_BYTES. A table can look small in row count yet sit at the top of this card because of a long Time Travel window or a heavy churn rate filling Fail-safe. The headline is shown in GB (bytes / 1024^3). Because top tables drive storage cost, this card is the natural entry point for a storage clean-up: high-churn staging tables, un-pruned event logs, and over-retained clones are the usual suspects. The time window is RT, refreshed on the standard cadence (note that TABLE_STORAGE_METRICS itself carries up to ~90 minutes of view latency in ACCOUNT_USAGE). There is no alert threshold on this card; it is informational, feeding capacity planning rather than paging anyone.
Reconciling against the source
Confirm the figure in Snowflake by queryingSNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS ordered by ACTIVE_BYTES + TIME_TRAVEL_BYTES + FAILSAFE_BYTES + RETAINED_FOR_CLONE_BYTES descending, or browse Snowsight → Admin → Cost Management → Consumption → Storage. Minor differences come from ACCOUNT_USAGE latency (up to ~90 minutes) and from whether Time Travel and Fail-safe bytes are included; this card counts the full physical footprint, not just live data. For the account-wide total, pair with Storage Used (TB).