feat: model size status page

[royendo]

as discussed: https://rilldata.slack.com/archives/CTCJ58H3M/p1767734884155469

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[royendo]

a first pass at getting something in while project status 2.0 gets started as well as https://linear.app/rilldata/issue/PLAT-376/instrumentation-for-physical-table-size-of-models

[royendo]

fixed bug, where values not shown unless action done on cloud, now it updates automatically: https://www.loom.com/share/825b70c51d234177a8949d7c920e4894

[royendo]

when not materialized:

[ericpgreen2]

Thanks for taking this on! I've been thinking about the design for this feature and want to propose a different direction before we proceed.

The current approach adds a "Size" column to the existing Resources table. While this works, I think it mixes two conceptually different concerns:

1. Resources table = "Is my deployment healthy?" (reconciliation status, refresh times, errors)
2. Table metrics = "How much data do I have?" (size, row count, column count)

This is why most rows show "-" for size — only Models map to database tables. Explores, Metrics Views, Canvas, etc. don't have a "size" concept.

Proposed Alternative: Separate "Tables" Section

I'd recommend mirroring the CLI's approach, where rill project status and rill project tables are distinct commands:

Resources
┌──────────────┬─────────────────────┬────────┬───────────────┬──────────────┐
│ Type         │ Name                │ Status │ Last refresh  │ Next refresh │
├──────────────┼─────────────────────┼────────┼───────────────┼──────────────┤
│ Model        │ bids_data_model     │ ✓      │ Jan 12, 9:05  │ -            │
│ Metrics View │ bids_metrics        │ ✓      │ Jan 12, 9:05  │ -            │
│ Explore      │ bids_explore        │ ✓      │ Jan 12, 9:05  │ -            │
└──────────────┴─────────────────────┴────────┴───────────────┴──────────────┘

Tables
┌─────────────────────┬───────────┬─────────────┬───────────┐
│ Name                │ Row Count │ Column Count│ Size      │
├─────────────────────┼───────────┼─────────────┼───────────┤
│ bids_data_model     │ 1,854,664 │ 31          │ 46.7 MiB  │
│ auction_data_model  │ 82,995    │ 9           │ 952.4 MiB │
└─────────────────────┴───────────┴─────────────┴───────────┘

Benefits:

• Cleaner separation of concerns (deployment health vs. data volume)
• No empty columns — every row in the Tables section has meaningful data
• Mirrors CLI experience (rill project tables output)
• Room to add row count and column count (like CLI) without cluttering the Resources table
• Simpler data model — no need to join two APIs with matching logic

Trade-offs:

• More UI surface area (two tables instead of one)
• Users need to look in two places

What do you think? Happy to discuss if you see it differently or have concerns with this approach.

---

Specific code comments (if we proceed with current approach):

1. selectors.ts — The caching and preloading logic is quite complex (~200 lines). If we go with a separate Tables section, this could be simplified since we'd just call OLAPListTables directly without needing to join with resources.

2. ProjectResourcesTable.svelte — The {#key tableSizes} block will cause the entire table to re-render when sizes load. This might cause a jarring UX with the table flickering.

---

Developed in collaboration with Claude Code