interactive-story/plan/13-memory-embedding-cost.md

13 — Memory-bank embedding cost (round three of the egress work)

Goal: stop every turn fetching the entire memory bank's embeddings. Measured at 3,024 KB per turn on adventure 25 against 129 KB for everything else a turn reads — the memory bank is ~96% of a turn's database traffic, and it is fetched fresh every single turn to pick memory_top_k = 5 memories.

Found 2026-08-16 while designing the story tree (see 14-phase-story-tree.md), because memory retrieval is the one read a tree cannot window — it is long-range recall by design, so it always spans the full path. That makes this the cost floor of a turn under the tree, which is why it lands first.

The measurement (production, Neon SQL editor)

SELECT count(*), avg(json_array_length(embedding))::int,
       avg(length(embedding::text))::int,
       pg_size_pretty(sum(length(embedding::text))::bigint)
FROM memories WHERE embedding IS NOT NULL;
--  134 memories | 1536 dims | 30,971 bytes each | 4,053 kB total

adventure	active	fetched	per turn
25	100	100	3,024 kB
21	18	18	545 kB
12	12	12	363 kB
20	4	4	121 kB

Break-even against the rest of a turn is 4.2 memories, i.e. about action 25. Every adventure past that is dominated by this.

active == fetched everywhere: nothing has been evicted yet, so the Python-side forgotten filter currently costs nothing. It becomes a real leak the moment eviction starts.

Why round two missed it

retrieve_memories needs settings.embedding_model, and embedding providers are BYOK-only by construction — they never touch the demo key. So the public demo never embeds anything, and the round-two stress harness (which had no embedding model configured) measured the turn loop with its heaviest read switched off. The 23.0 MB figure for a 200-action playthrough is the memory-bank-off number; with it on, adventure 25 is closer to 300 MB.

Rule going forward: any egress measurement must run with an embedding model set.

Root cause

memorybank.py:208

candidates = [m for m in adventure.memories if not m.forgotten and m.embedding]

Walks the relationship, so every memory row for the adventure loads with its embedding. embedding is Mapped[list] on a JSON column — 1536 floats serialised as text is ~31 KB. Cosine ranking happens in Python (a deliberate choice, documented at models.py:144), so all of it must cross the wire. The comment sized it by count ("fine at a few hundred") rather than by bytes.

Not the same bug as migration 36/37 — the column is not a repeating group and there is no denormalisation to fix. It is a format problem plus a fetch-frequency problem.

Decisions (settled 2026-08-16)

• Packed float32, keep 1536 dimensions. 31 KB → 6 KB, a straight 5x, with zero retrieval-quality risk. Explicitly rejected dropping to 512/768 dims: the size fix plus the cache makes the extra 3x unnecessary, and it would have meant re-embedding.
• No re-embedding. Dimensions are unchanged, so the migration is a pure format conversion of the 134 existing rows — read the JSON, write packed bytes, no API calls. One-time 4 MB read.
• In-process cache alongside the size fix, not sequenced after it. Turns for one adventure arrive back-to-back, so a dict keyed by adventure id takes steady-state cost to ~0. 100 vectors as float32 is 600 KB of RAM — negligible.
• memory_bank_capacity 200 → ~80. Taken on quality grounds as much as cost: ranking 200 memories to pick 5 dilutes retrieval. Note this will start evicting on adventure 25 immediately (it sits at 100).
• Not pgvector. It is the structural answer and would keep vectors in the database entirely, but it breaks SQLite dev parity — which the codebase protects deliberately (context/history.py:42, the replace()/trim() dialect dance). Revisit only if the bank grows past what Python cosine can handle.

Work, in order

1. Rebuild the byte-meter harness — in the repo this time. backend/tools/dbmeter.py
   • stress_session.py. The originals lived outside the repo and are gone. Default it to running with an embedding model configured, since that omission is precisely what hid this finding. Do this first so every item below is measured, not assumed. Done 2026-08-16 — see the baseline below.
2. Migration 38 — memories.embedding_blob (LargeBinary). Done. Backfill in Python (struct.pack(f"<{n}f", *vec)); the conversion cannot be expressed in portable SQL, so unlike migration 36/37 this one does pay a one-time 4 MB read. Drop the old JSON column in a follow-up migration once verified, not in the same one.
3. Read path. Done. retrieve_memories queries memories directly with forgotten = false AND embedding_blob IS NOT NULL in SQL, not Python. Unpack with struct/numpy. Same for _evict_over_capacity and _embed_pending, which walk the same relationship for a count and for the unembedded rows (see the baseline above).
4. Vector cache. Done. Keyed by adventure_id, bounded to 8 adventures. It turned out to need no invalidation callbacks at all — see below.
5. Capacity default 200 → 80. Done (migration 41, only rows still on the old default). Eviction checked at scale first: trimming a 100-memory bank to 80 costs 0.8 kB and eight statements, and reads no vectors at all.
6. Infinite scroll upward in Play.jsx for the remaining 423 KB page load of a finished adventure — the last open item from round two. Load the newest turns, fetch older ones as the reader scrolls up.

Baseline from the harness (2026-08-16)

python -m tools.stress_session, 200 actions × 4 KB, 100 memories × 1536 dims:

shape	fetched	memories' share
GET /adventures (index)	0.7 kB	—
GET /adventures/{id} (page load)	426.7 kB	—
POST /adventures/{id}/actions (one turn)	3,258.7 kB	96%
GET /adventures/{id}/context (Insights)	3,223.7 kB	97%
run_post_turn (background)	3,139.1 kB	100%

It reproduces both production figures independently — 426.7 kB against the measured 423 KB page load, 3,258.7 kB against 3,024 + 129 kB for a turn, and 31.4 KB per embedding against 31.0 KB. --no-embeddings reports 112.0 kB for the same turn, so the round-two blind spot is now a 29x gap anyone can see in one flag.

Two findings the SQL measurement could not have shown, both the same root cause in a different caller:

• run_post_turn fetches the whole bank again, every turn. _evict_over_capacity walks adventure.memories to count the active ones, and _embed_pending walks it to find the unembedded ones. So a played turn actually costs ~6.4 MB, not 3.2 — the original estimate was half the real number.
• Insights pays it a third time, on a page the player can open repeatedly without spending a turn.

So step 3 below is not just retrieve_memories: every walk of adventure.memories has to go. _evict_over_capacity wants a count and an ordering, _embed_pending wants rows where embedding IS NULL — neither needs a single vector, and both are pure SQL.

After (2026-08-16, same harness, same fixture)

shape	before	after (cold)	after (warm)
POST .../actions (one turn)	3,258.7 kB	723.4 kB	122.3 kB
run_post_turn	3,139.1 kB	0.7 kB	0.7 kB
GET .../context (Insights)	3,223.7 kB	117.9 kB	117.9 kB
GET .../memories (drawer)	~3,138 kB	23.6 kB	23.6 kB

A played turn is turn + post_turn: 6,398 kB → 123 kB once warm, a 52x cut. The targets above were ~700 kB cold and ~130 kB warm, so both were met.

Steps 2–5 landed together, because they are one deployable unit: the columns are no use unless something reads them, and deferring them breaks the old readers. Two additions the plan did not anticipate:

• memories.embedded, a boolean beside the blob (migration 39/40). Once the vectors are deferred, every "does this have an embedding?" check becomes a lazy load — an N+1 of 6 KB reads down the Memories drawer. Same shape as actions.variant_count beside actions.variants, and the same reason.
• The cache needs no invalidation callbacks. Vectors only ever change through set_vector, which drops the one entry; everything that removes a memory from play leaves the catalogue query, and entries missing from the catalogue are dropped on the next read. So eviction, deletion and pruning need no hooks and cannot be forgotten. Vectors are held as array("f") — 6 KB each, matching the column; a list of Python floats would have been eight times the plan's RAM estimate.

Remaining: step 6, infinite scroll upward in Play.jsx. The page load is unchanged at 426.7 kB and is now the largest single read in the app.

Guardrails to add with this work

• Query-count / byte assertions per endpoint, extending the test_egress.py idea: assert an endpoint issues at most N queries and fetches under X KB against production-sized fixtures. This class of bug is invisible at ten rows.
• Explicit column projections on read paths. List endpoints name the fields they need rather than loading whole entities, so the next heavy column is opt-in. This is the structural version of what deferred=True does by hand.
• Row-width review rule. Any new large column justifies itself or goes out-of-line. actions now carries five JSON columns.

Deliberately not taken: moving context_snapshot out of the database. It costs nothing on reads now that it is deferred, and storage is ~$0.02/mo. Revisit only if backups or storage start to hurt.

Revisit it. That call weighed egress and got egress right, but it never weighed the free tier's storage ceiling — see "Storage, which this plan did not cost" below.

Verification

• Harness: python -m tools.stress_session, memory bank on, before and after, against the baseline table above. Target for the turn shape is 3,258 kB → ~700 kB cold, ~130 kB warm (the cache leaves only what a turn reads besides the bank). run_post_turn should fall to roughly nothing: neither of its two walks needs a vector at all.
• Re-run the round-two shapes with an embedding model configured, so the 200-action playthrough number is finally honest.
• The existing test_egress.py guard must still pass — nothing here should touch the deferred action columns.

Verified on production, 2026-08-17

Two things were still taken on trust when this shipped: every measurement had run on SQLite, and every number came from a synthetic fixture. Both are now checked.

The migration landed on real Postgres

schema_version reads 41, matching the repo's LATEST_VERSION. The live schema has embedding_blob bytea and embedded boolean, so the {dialect: sql} map in migration 38 spells BYTEA correctly against a real server — the one thing tests could not prove, since test_migration_38_is_spelled_for_both_dialects only inspects the SQL string. The backfill is complete: 134 memories, embedded = 134, embedding_blob = 134, no stragglers and no rows skipped as malformed.

The 5x is real, on real vectors

	bytes	per memory
embedding (JSON)	4,150,121	30,971
embedding_blob (float32)	823,296	6,144

5.04x, against the plan's predicted ~31 KB → 6,144 B. The largest real bank is 100 memories = 614,400 B of vectors, so the old code fetched ~3.10 MB per retrieval on that adventure — which is where the 3,153 kB measured on production came from. That figure is now fully accounted for.

SQLite and Postgres agree

tools.stress_session gained an AIDND_STRESS_DATABASE_URL escape hatch and was run against a throwaway Neon database at the default fixture (200 actions, 100 memories):

shape	SQLite	Postgres
index	4.1 kB	4.1 kB
page load	426.7 kB	425.0 kB
one turn, cold	723.4 kB	722.3 kB
one turn, warm	122.3 kB	121.1 kB
Insights	117.9 kB	116.7 kB
Memories drawer	23.7 kB	21.7 kB
run_post_turn	0.7 kB	0.6 kB

Within 0.5% everywhere. The dialect caveat in the harness docstring is real but small: what dominates is which columns get asked for, and the ORM decides that identically. The warm turn spends 1.7 kB on memories, 1% of the read — the cache behaves on psycopg exactly as it does on SQLite.

The page load is worse than modelled, for a different reason

The synthetic fixture is ~2x heavier per action than production: 994 B/action real against ~2,133 B/action synthetic, so a real 200-action adventure is ~194 kB, not 427. But the largest real adventure is 607 actions, not 200, and costs 589.5 kB in one response. Step 6 is more urgent than this plan assumed, and for the opposite reason to the one modelled — stories get longer than the fixture, not heavier.

Worth fixing the fixture's narration size when step 6 lands, so the harness stops flattering the per-action figure while understating the length.

Storage, which this plan did not cost

context_snapshot is 150.8 MB of uncompressed JSON across 944 actions — ~163 kB a row on average, and ~232 kB a row in the largest adventure, against the ~74 KB/row the comment in models.py claims. TOAST compresses it to ~89 MB on disk, but octet_length is what would cross the wire, because Postgres decompresses before sending. Deferral is the only thing standing between a bulk read and a 137 MB query.

The database is 99.6 MB total, of which actions is 88.9 MB. Neon's free tier is 512 MB. At 94 kB of disk per action that ceiling arrives at roughly 5,400 actions, and 944 are already stored. So the "$0.02/mo, leave it in the database" call above is wrong for the tier this actually runs on — not because reads cost anything, but because the free tier meters storage, and that is the constraint with a cliff. Dropping the dead memories.embedding column reclaims 4.05 MB (4%), which helps and does not solve it.

None of the numbers above required reading a single row of anyone's content: counts, octet_length sums and catalog sizes only.