Virtual Materialized Views for Atlassian Forge SQL: A Two-Level Caching Approach in forge-sql-orm

If you build non-trivial apps on Atlassian Forge SQL, sooner or later you run into the same limitation: TiDB in Forge does not support materialized views. This becomes painful as soon as your application needs read-heavy features built on complex joins, aggregations, or denormalized relational data. In practice, this usually leaves you with two unattractive options: recompute expensive queries on every resolver call and risk hitting strict Forge SQL limits (like the 5s connection timeout or 16MB memory usage), or manually maintain precomputed tables and synchronization logic, which quickly turns into brittle application code. In forge-sql-orm , I’ve implemented a two-level caching approach that acts as a virtual materialized view at the application layer. The first level is an invocation-scoped in-memory cache that eliminates duplicate queries during a single resolver execution. The second level is a persistent cross-invocation cache backed by @forge /kvs, allowing expensive results to