v0.3.0

⚡ Performance release. Rendering a public page issued one query per collection entry and wrote to the database on every read of a singleton. Both are fixed.

On a real site, a page combining a singleton and a listing goes from roughly fifteen database round trips to one or two, and to zero once the cache is warm.

If your queries feel slow, also check that your server function runs in the same region as your database — on a serverless host, a default deployment can put the two on different continents, which adds ~90 ms to every query. No amount of caching recovers that.

👉 Changelog

🔥 Performance

• store: Reading a collection costs one query instead of N+1 — listCollection re-read each row through getResult even though findMany had already returned its payload
• store: Reading a singleton no longer writes — the per-read upsert took a row lock and wrote WAL just to serve content
• store: The sitemap and the public listing share one read of a collection's rows
• store: Instance-level cache of published reads, cacheSeconds (5 by default, 0 to disable), dropped after every write
• variables: Interpolation returns branches holding no variable as they are instead of rebuilding them

🩹 Fixes

• store: A shape drift that never converges no longer writes on every read — a reader persists it once per process, so the storage-envelope migration still lands on first read
• store: Writers never read the cache, so the updatedAt they lock on always comes from the database and a stale key cannot become a spurious conflict
• store: Drafts are never cached, so the preview panel still shows a save immediately

🚀 Features

• module: cacheSeconds option

✅ Tests

• The fake Prisma client counts the queries a call sends, so a return to N+1 or to writing during a read fails the suite instead of merely being slower

Full Changelog: v0.2.0...v0.3.0