Self-hosted: disk-backed storage option — pglite (memFS) holds the entire corpus in RAM, RSS scales with total corpus not working set

[maxsap]

Summary

Self-hosted supermemory-server holds the entire corpus in RAM, so resident memory scales with total corpus size rather than working set. On a 16 GB host with only ~5,000 memories (~2 GB on-disk store), RSS sits at 7 GB baseline and ratchets to ~11 GB under ingest, wedging the process. Please consider a disk-backed / on-demand storage option so memory scales with the working set, not the whole database.

Evidence

• /proc/<pid>/smaps on a running server: RSS is ~99% anonymous; the single largest anonymous region tracks the on-disk store size (~2 GB), and the data file is not mmap'd at all (file-backed mappings total <100 MB: the binary + libonnxruntime.so).
• RSS only grows and never returns to the OS — it stays at the post-ingest peak until a full process restart.
• The self-hosting docs confirm this is by design: "the built-in local embeddings and storage engine have a fixed footprint that exists before any document is processed."

Root cause

The storage engine is pglite (Postgres compiled to WASM) in its default memFS mode, which keeps the whole database — table data plus the pgvector/HNSW index — in WASM linear memory: decrypted, resident, and non-shrinking (WASM linear memory never releases pages back to the OS). Relevant upstream pglite issues:

• About memory usage  electric-sql/pglite#406 — memFS keeps all data files in RAM (maintainer-confirmed)
• Memory Leak in complex production app (256mb+ memory quickly allocated in application) electric-sql/pglite#802 — unreleased WASM heap buffers (memory not returned)
• [BUG]: PGLite 0.4.0...3 stops working after exceeding some amount of data electric-sql/pglite#965 — data-size memory cliff (fixed in pglite ≥ 0.4.4)

Requests

1. A disk-backed / on-demand VFS option for self-host (or expose the pglite dataDir/VFS + shared_buffers/work_mem startParams) so RSS scales with the working set instead of the full corpus. Today the only storage-related env is SUPERMEMORY_DATA_DIR (location of the persisted copy), with no way to bound the in-memory footprint.
2. Please document which pglite version the standalone binary embeds. If it predates 0.4.4, bumping it would pick up the fix auto scroll bug and mobile responsiveness #965 memory-cliff fix.

Impact

SUPERMEMORY_EMBEDDING_RAM_LIMIT caps ingest headroom but not the corpus baseline, so a self-hosted deployment currently needs RAM ≥ (full corpus + index) + ingest headroom, which does not scale for memory-heavy single-tenant use cases. A disk-backed option would make the resident footprint bounded and predictable.

Environment

• supermemory-server linux-x64 standalone binary, version server-v0.0.3 (pinned; can't move to 0.0.5+ due to Self-hosted v0.0.5 upgrade skips profile_buckets migration; /v4/profile returns 500 #1293)
• Storage: local encrypted data dir (~2 GB, ~5,000 memories, 768-dim)
• Embeddings: local ONNX (Xenova/bge-base-en-v1.5)

[linear-code]

ENG-1125