# Why does the Storage total on Home/Explorer differ from the Storage page?

URL: https://select.dev/docs/reference/faq/using-select/why-does-the-storage-total-on-home-explorer-differ-from-the-storage-page
Index of all SELECT docs: https://select.dev/docs/llms.txt

> Explains that account-level totals include retained clone bytes that dropped-source objects can no longer attribute at the database or table level.

In SELECT, the Storage totals on the Home and Account Explorer pages come from `SNOWFLAKE.ACCOUNT_USAGE.STORAGE_USAGE` (account level). This view includes `retained_for_clone_bytes` in the grand total and matches Snowflake billing. It is aggregated at `date + account`, so there is no per-database or per-table detail in this view.

The Storage page uses more detailed sources, including `SNOWFLAKE.ACCOUNT_USAGE.DATABASE_STORAGE_USAGE_HISTORY` (per-database history) and `SNOWFLAKE.ACCOUNT_USAGE.TABLE_STORAGE_METRICS` (per-table metrics). These do not attribute bytes from dropped original objects that still back zero-copy clones. Once the original object is dropped, those retained bytes continue to appear only in the account-level total in `STORAGE_USAGE`, not under any active database or table. As a result, the detailed sums can be lower than the grand total.

**Example**  
You clone `fct_sales` to `fct_sales_backup`. Billing stays with the original. If `fct_sales` is later dropped, Snowflake still charges for the shared data and reports it in `STORAGE_USAGE` as `retained_for_clone_bytes`. The original no longer appears in `DATABASE_STORAGE_USAGE_HISTORY` or `TABLE_STORAGE_METRICS`, so the detailed view will not include those retained bytes.

This is a modeling limitation of the current `ACCOUNT_USAGE` views.