[bjacobso]

Why

Every ConfigStore.resolveRef, snapshotById, commit and setRef called load(). That reads every config record (objects, types, revisions, snapshots, refs) and rebuilds every snapshot's node tree. ConfigRuntime.evaluate resolves a ref on every call, so its cost grew with the whole config history. On the in-memory store, each of load()'s five entity-type reads also scanned every fact. WorldVM works around this by caching ref resolutions itself.

Config staying in triples is not the problem. It keeps releases, ref moves and application facts in one transaction and one journal, with bitemporal ref history and Datalog impact queries. The access pattern was the problem.

Change

• resolveRef reads the ref entity, then snapshotById.

• snapshotById reads the snapshot record and only the objects reachable from its root, one batched entities read per tree level.

• Caching.

  • Immutable records are cached by identity for the life of the service: object bodies and type expressions by content ID, and snapshot records by ID.
  • Decoded trees are cached only until :triplex/valid-under changes. A node's type comes from validUnder, which later releases can extend. One dependencyState call checks this; it's an indexed query on SQL, and it stays correct when another process commits.

• commit hands the pure InMemoryConfigStore.commit a partial store:

  • the input subtrees' stored objects and schemas;
  • those objects' revision histories;
  • the latest snapshot.

  It checks objects the transition mints outside the inputs (the snapshot root) before persisting them.

• setRef and reverseDependencies read single records.

• load() is unchanged. The CLI and recheck still use it for the whole-store view.

Breaking (pre-1.0, minor changeset): ConfigStore.commit no longer returns store. Nothing in the repo used it; call load() instead.

The first commit is PR #46, cherry-picked unchanged: entity-type matches at a temporal basis read the type index instead of scanning. The targeted reads still do a few typed reads, and this PR shouldn't depend on #46 landing first. If #46 merges first, this rebases cleanly.

Numbers

In-memory KV, Node 24. Each release has 21 config nodes. Each figure is the median of five warm ConfigRuntime.evaluate calls on one rule.

Releases	Facts in store	main without #46	main + #46	This PR
10	0	10 ms	1.6 ms	0.46 ms
200	0	125 ms	7.8 ms	1.4 ms
50	16,000	—	2.4 ms	0.6 ms
50	160,000	474 ms	—	0.5 ms

• Sources: the 160k row and the "without kv: answer entity-type matches at a temporal basis from the TYPE index #46" column were measured on the In-memory bulk loads: segments attached in one transaction, position refs, faster KV writes #47 branch (its faster KV writes are needed to load that many facts). The 160k "this PR" figure is this PR stacked on In-memory bulk loads: segments attached in one transaction, position refs, faster KV writes #47.
• Cost now: evaluate costs one dependencyState call, one ref read and a cache hit, whatever the history size. The first evaluate after a validUnder change rebuilds only the requested snapshot (12 ms at 200 releases).
• Commit isn't faster on main's in-memory backend, and is slower with many facts (16k facts: 29 ms → 46 ms). Its targeted reads touch the entity, attribute and value indexes, and on main the in-memory backend re-sorts a whole index after every write.
  • In-memory bulk loads: segments attached in one transaction, position refs, faster KV writes #47 replaces that with an incremental merge whose small merges are a block copy. Stacked on In-memory bulk loads: segments attached in one transaction, position refs, faster KV writes #47, commit takes 22 ms at 16k facts and 72 ms at 160k (54 ms at 200 releases with no facts, against main's 60 ms).
  • On SQL backends these are indexed reads.
  • One part still grows with history: finding the latest snapshot reads every snapshot record. A head pointer would remove it, but needs a new fact, so I left it.

Tests

test/config/ConfigStoreReads.test.ts:

• Differential: a five-release sequence produces the same snapshot IDs, sequence numbers, parents and minted revisions as the pure InMemoryConfigStore. That includes a release that only proves an existing body valid under a wider schema, and a revert to an earlier release. Afterwards the full load's revisions, objects, schemas and seq match.
• Cross-instance: a second ConfigStore over the same triples commits, moves refs, and extends validUnder on a node already in a cached snapshot. Every resolveRef and snapshotById on the first instance still deep-equals what load() reconstructs, including node types. With the validUnder freshness check disabled, this test fails.
• No scans: resolving a ref (twice) and reverseDependencies issue no entity-type reads.

All existing config, CLI, HTTP, dashboard, example and integration tests pass unchanged. pnpm check is green.

🤖 Generated with Claude Code