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

[royendo]

I've got no strong opinions at the moment, thought it would be easier to use an existing space is all!

And agreed, I've more or less completed the PRD to revamp our status pages, waiting for Di to return from holiday to get that one moving.

Will re-iterate with a separate table!

[royendo]

@ericpgreen2 are you aware of any issues with running query from Rill Cloud? im getting 401s and some other issues due to how rill project tables is designed. Row Count isn't the most important so we can remove it, too. LMK!

[royendo]

note to self: https://github.com/rilldata/rill/actions/runs/20965177038/job/60253446299?pr=8604#step:14:865
Add navigation to project status page

[royendo]

Short term Solution: Remove row and column count from UI.
Long term solution: discuss possibility to re-work api to add row count.

For now, will remove the UI features.