One Wikimedia edit firehose, indexed two ways at once: the pages edited just now, and the editors editing just now — each with its newest edits nested, side by side. A tiny machine materializes both queries once and keeps them exact on every change streaming in. This page didn’t run them; it attached to the results. No refetch, no cache to invalidate.
page .orderBy("last_ts", "desc") .limit(20) .sub("edits_recent", edit, { parent: ["id"], child: ["page_id"] }, (e) => e.orderBy("ts", "desc").limit(5))
editor .where.edits(gt(1)) .orderBy("last_ts", "desc") .limit(20) .sub("edits_recent", edit, { parent: ["name"], child: ["user"] }, (e) => e.orderBy("ts", "desc").limit(5))
The live boards above are served from results the engine maintains. To prove that matters, here is the same nested “just edited” query, in this tab, refreshed two ways as a synthetic corpus grows: re-running it from scratch (what a cache does on every miss) vs applying just the change (incremental view maintenance). One climbs with the dataset. One doesn’t — cost tracks the change, not the table.