# Storage statistics

> How much a project, dataset or table costs to keep (logical vs physical bytes, active vs long-term, time travel and fail-safe), and whether switching the dataset's billing model would save money. Per-column sampling shows which columns are worth shrinking.

Source: https://docs.querylab.io/data-management/storage-stats/

**dim_vehicle · Storage**

**Vehicle Dimension**
  **Storage Breakdown**

Table level. Breakdown percentages are of total physical bytes.

## Opening it

Right-click a project, dataset or table in the schema tree → **Show Details**, then the **Storage** sub-tab. Each level answers a different question.

- **Project**: totals across datasets, a dataset grid (tables, rows, logical/physical GB, average compression, cost columns) and a table grid.
- **Dataset**: a cost summary for the dataset's billing model, and one row per table.
- **Table**: summary tiles, the storage breakdown above, and on-demand column analysis.

A toggle switches between **SQL** (billed, fast: you see the dry-run estimate and confirm with **Run**) and **API** (free, slower on big datasets).

## Billing model comparison

The dataset view prices your storage under both models and tells you which is cheaper:

**Cost Summary**

Dataset cost summary. Click the 'If switched to' block to get the ALTER SCHEMA statement in a new tab.

| Model        | What's billed                                                                        | Free                   |
| ------------ | ------------------------------------------------------------------------------------ | ---------------------- |
| **Logical**  | Active + long-term logical bytes                                                     | Time travel, fail-safe |
| **Physical** | Active + long-term physical bytes, plus time travel and fail-safe at the active rate | —                      |

Prices are per region; the app uses your dataset's. Long-term means not modified for 90 days. Well-compressed tables usually win on physical; tables with heavy time-travel churn don't.

## Column analysis

On a table, expand **Analysis Options** and click **Analyze**. Logical bytes per column are exact; physical bytes and compression are estimated by sampling the table, so the grid marks them _(est.)_.

<div class="set-g">Partition Scan</div>
    - All Partitions (slow on large tables) (selected)
    - Last 7 days
    - Last 30 days (selected)
    - Last 180 days
    - Analyze Physical Storage (selected)
    <div class="set-g">Sampling Strategy</div>
    - Hybrid (70% newest + 30% random) (selected): Best for most tables. Combines recent data with random sampling.
    - Newest data only (100% from end): Good for append-only tables.
    - Random probes (100% scattered): Good for uniform data distribution.
    <div class="set-g">Sample Size</div>
    - Fast: 500 samples per column
    - Standard (selected): 1000 samples per column
    - Thorough: 2000 samples per column

Analysis Options. Defaults shown.

The column grid has: Level, Column, Type, Compression, Logical (GB), % of Parent, Physical (GB), % of Parent, Cost (Logical), Cost (Physical), NULL %. _% of Parent_ is relative to the enclosing STRUCT, so nested fields add up to their parent; filter by level to flatten deep schemas.

### Shrinking UUID and hash columns

Columns holding UUIDs or hex hashes (MD5, SHA-256) as STRING get a recommendation with a priority: `FARM_FINGERPRINT` (INT64, roughly 80% smaller) or `BYTES` (16 bytes, roughly 60% smaller), each with the estimated saving, collision risk and a ready migration script. Columns where the change wouldn't save more than 0.1 GB are left alone.

Column reports count against the free tier (_N of M free reports this month_) and are saved under **Recent Reports** so you can reopen one without resampling.