LearnNewsExamplesServices
Frontmatter
id14079
titleMemory Core Chroma store 2.5GB bloat — analysis + remediation roadmap
stateOpen
labels
enhancementepicaiarchitecture
assigneesneo-opus-ada
createdAtJun 26, 2026, 12:24 PM
updatedAtJul 2, 2026, 7:49 PM
githubUrlhttps://github.com/neomjs/neo/issues/14079
authorneo-opus-vega
commentsCount6
parentIssuenull
subIssues
14192 Reclaim the unused Chroma FTS5 index (~495MB) — no full-text consumer; governed drop, Chroma-tolerance V-B-A first
14193 Field↔document de-dup (~910MB) — consumer-aware refactor to one canonical representation
subIssuesCompleted0
subIssuesTotal2
contentTrust
projected
quarantined0
signals[]
blockedBy[]
blocking[]

Memory Core Chroma store 2.5GB bloat — analysis + remediation roadmap

Open Backlog/active-chunk-2 enhancementepicaiarchitecture
neo-opus-vega
neo-opus-vega commented on Jun 26, 2026, 12:24 PM

Context

The shared Chroma store (.neo-ai-data/chroma/unified) is 2.5GB for ~22.5k live memory rows — heavy bloat. Investigated 2026-06-26 (triggered by the aborted neo-agent-memory repair: 22553 rows, 13969 re-embedded, 1 unrecoverable, ABORTED, kept a resumable shadow, "Final Size 2502.72 MB"). Split: chroma.sqlite3 1.5GB + HNSW vector segments ~1.07GB.

Culprits (by reclaimable size)

Culprit Size Mechanism
Abandoned shadow neo-agent-memory-shadow-1782425298937-* ~600–800MB The aborted repair left a full repaired duplicate (355MB HNSW + its metadata/FTS) alongside the corrupted live original (147MB HNSW — small because it's missing vectors). The shadow is the GOOD copy; the live one is broken.
Unused FTS index embedding_fulltext_search_* 495MB Chroma builds an FTS5 index on every document; Memory Core queries are vector-only (V-B-A'd: zero where_document/$contains in the MC query path). KB query path TBD.
Metadata embedding_metadata* 794MB 820k rows / 66k embeddings (~12 fields each); chroma:document 116MB + split thought/response/prompt 94MB (redundant with the document) + KB content.
SQLite free pages 191MB (12%) Dead space from the re-embed churn (13969 re-embeds = delete+insert); the file never shrank. Reclaimable by VACUUM.
447 orphan test-* collections low data Pre-isolation leftovers. Tests now use a separate Chroma daemon + data dir (per #14022) and no longer write to prod — so this is a one-time GC, not a live-leak fix.

HNSW segment map: KB 532MB (biggest, legitimate), shadow 355MB, neo-agent-memory 147MB, sessions 21MB, graph 10MB. Orphan metadata rows: 0 (clean). HNSW dead-nodes: ruled out (the original/shadow size gap is the corruption, not dead nodes).

Remediation (prioritized)

  • Complete the aborted repair — resolve the 1 unrecoverable row, promote the shadow, drop the corrupted original (~600–800MB). Owner: the recovery work (#14066/#14027).
  • Delete the 447 orphan test-* collections (pre-isolation leftovers; #14022 isolation holds, so a one-time GC — careful dry-run first, prod store).
  • VACUUM the SQLite to reclaim the 191MB free pages (after the repair + deletes).
  • Drop the unused FTS index (495MB) — first confirm the KB query path is also vector-only (or scope to MC), then a Chroma migration removing FTS while keeping documents.
  • Assess the metadata content-redundancy (~94MB: chroma:document + split prompt/thought/response) — pick one source of truth.

Estimated: 2.5GB → ~1.1–1.3GB after the shadow de-dup + FTS removal + VACUUM + test-cleanup.

Related

  • #13999 (Memory Core corruption-recovery / stability theme), #14022 (test Chroma isolation), #14066 / #14027 (the recovery work that completes the repair / de-dups the shadow).

Authored-by: @neo-opus-vega (Vega, Claude Opus 4.8)

tobiu referenced in commit e11119a - "fix(ai): write-ahead KB resume marker — no orphan shadow on double failure (#14176) (#14180) on Jun 27, 2026, 3:11 AM