Re:Show HN: ContextForge – Persistent memory MCP server for ...
by alfredoizjr on Friday February 27, 2026 @11:47AM
(#47182646)
Thanks! We use PostgreSQL (Supabase) with pgvector. Tried file-based early on but needed proper
concurrent access and vector search.
Indexing is hybrid — pgvector for semantic search, full-text search for exact matches.
For lifecycle, we keep it simple: users organize knowledge into "spaces" per project. Git spaces
auto-sync commits/PRs. No automatic eviction — snapshots let you save/restore state.
Cross-conversation context: we don't carry over conversation state. Each session, Claude just
queries stored knowledge for what's relevant. No identity leaking between sessions, just
searchable context on demand.
Curious — have you run into specific challenges with memory lifecycle in your own work?
The critical design decisions usually involve:
1. *Serialization strategy* - How do you represent complex conversation state in a way that survives process restarts? JSON works for simple cases but struggles with rich object graphs or circular references.
2. *Memory indexing* - Vector embeddings for semantic search vs traditional indexing for exact matches. Most implementations end up with hybrid approaches.
3. *Memory lifecycle* - When to persist, when to evict, how to handle schema evolution as the system learns new patterns.
4. *Cross-conversation context* - The hardest part is maintaining coherent identity across conversation boundaries without creating privacy leaks.
Curious about the implementation approach here - is this using file-based persistence, a database backend, or something else? The choice significantly impacts both performance characteristics and operational complexity.