Decide: which result sections to normalize into tables vs versioned JSON output #18

New issue

Closed

opened 2026-07-17 01:17:59 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-17 01:17:59 +00:00

Contributor

Open Question carried over from docs/roadmap.md.

Which result sections should be normalized into tables later, if any, versus stored as versioned JSON output?

Currently the whole calculation output is a single JSON blob. That has already caused real problems: JSONB parameter bugs and a 344KB column being loaded on every status poll, both of which required targeted fixes.

Normalizing the sections that are queried or compared across homes/time - projections, quote comparison results - would avoid unpacking the blob to answer simple questions. Sections only ever read whole can stay JSON.

Related to the quote document storage work in v1.2.0, which is the same normalization pressure applied to inputs rather than outputs.

Open Question carried over from `docs/roadmap.md`. > Which result sections should be normalized into tables later, if any, versus stored as versioned JSON output? Currently the whole calculation output is a single JSON blob. That has already caused real problems: JSONB parameter bugs and a 344KB column being loaded on every status poll, both of which required targeted fixes. Normalizing the sections that are queried or compared across homes/time - projections, quote comparison results - would avoid unpacking the blob to answer simple questions. Sections only ever read whole can stay JSON. Related to the quote document storage work in v1.2.0, which is the same normalization pressure applied to inputs rather than outputs.

claude-bot added this to the Open Questions milestone

2026-07-17 01:17:59 +00:00

claude-bot added the

decision

label

2026-07-17 01:17:59 +00:00

claude-bot commented

2026-07-17 15:21:17 +00:00

Author

Contributor

Decision (Ryan, 2026-07-17): keep the calculation output as a versioned JSON blob; normalize into tables only the sections that get queried across homes or time — concretely, quote comparison results and projection summaries — and only when #10 (quote persistence) starts. Sections that are only ever read whole stay JSON.

This keeps the blob as the single source for whole-result reads (the 344KB-column and polling lessons already produced meta/output split + ETag handling), while giving the cross-cutting queries real columns when the first feature actually needs them.

Closing as decided; the normalization work itself lands with #10.

**Decision (Ryan, 2026-07-17): keep the calculation output as a versioned JSON blob; normalize into tables only the sections that get queried across homes or time** — concretely, quote comparison results and projection summaries — **and only when #10 (quote persistence) starts.** Sections that are only ever read whole stay JSON. This keeps the blob as the single source for whole-result reads (the 344KB-column and polling lessons already produced meta/output split + ETag handling), while giving the cross-cutting queries real columns when the first feature actually needs them. Closing as decided; the normalization work itself lands with #10.

claude-bot referenced this issue

2026-07-17 15:21:18 +00:00

Store quote documents as backend records #10

claude-bot closed this issue

2026-07-17 15:21:21 +00:00