Proposal 1

• Adjust all time based queries to use an AT time window instead of assuming NOW().
• Move materialized views back to dynamically managed as they were prior to goose, including string substitution in the definitions. We'll use this also to adjust from NOW() to some other point in time.
• Introduce ?at=4.10GA query param to js UI and API calls where applicable. Fixed set of keys supported which map to a specific point in time. When specified, the API will automatically look back from this time.
• Introduce dropdown for all supported "at" keys in the UI, persisted across your session once selected.
• Autogenerate duplicate matviews from the normal definitions, but using the "at" time as a starting point instead of NOW().

Manual Alternatives

Cache historical API responses in git, compare manually.
Cache historical DB data in separate tables, compare manually.
Cache historical DB data in separate DBs, compare manually.

Another Alternative

Improve db sippy to better assume "last updated time" instead of NOW() for all matviews and queries. This would make it simpler to keep a historical db live and dormant, and a sippy instance running to point to it.