Show HN: MCP Memory – Fast Agent Memory Using Google's OKF and SQLite FTS5
pcbmaker20
58 points
35 comments
August 13, 2026
Related Discussions
Found 5 related stories in 63.9ms across 4,128 title embeddings via pgvector HNSW
- Show HN: Adaptive Recall, persistent memory for AI assistants over MCP abratabia · 20 pts · July 12, 2026 · 62% similar
- Show HN: MCP-stama – An ultra-fast Rust MCP server with no dependencies stammanif · 71 pts · August 13, 2026 · 60% similar
- Show HN: I evaluated file, vector, graph and RL based memory frameworks pinglin · 13 pts · August 15, 2026 · 56% similar
- Show HN: A public AI whose memory is shared across all users adjohu · 70 pts · August 16, 2026 · 56% similar
- Show HN: An MCP server that turns async-work practices into tools benbalter · 17 pts · July 21, 2026 · 55% similar
Discussion Highlights (13 comments)
rcarmo
Nice to see more OKF-based approaches. My entry in this field is https://rcarmo.github.io/projects/memento/ , which I’ve been running for a few months now.
FitchApps
Looks very interesting. Can you explain for noobs why using Google's OKF format and not plain MD files?
clemens1010
did you test if that actually outperforms local claude code memory by any metric?
jrflo
Cool idea. Why is this beneficial over just using markdown files and allowing agents to grep for whatever they need? I've tried various MCP things in the past and I've found they tend to slow down the agent and waste tokens more than they end up helping, but a better memory system is 100% needed for agents.
bearjaws
Another week, another agent memory system that is about the same as grep in a memory/ directory.
myshapeprotocol
Using SQLite FTS5 for fast agent memory is such a pragmatic architectural choice. Great Show HN project.
healthycoder
How is this any different from all the other Memory stuff we have? mem0 etc etc that do the same thing?
0c3ca83
How is this different from what's built into Claude?
ksajadi
For those looking for similar tools, there is also https://markbase.cloud/ as a hosted service. (Disclaimer: we built it for internal use first and would like to open source with the community help as we don’t have much experience in OSS maintenance)
Alifatisk
What I do currently is having a markdown file named MEMORY.md at the root folder. Then, whenever I create a new conversation with an agent, I refer to that file. That file becomes the initial source of context and knowledge. At the end of an task, before I leave the conversation, I ask the agent to update MEMORY.md with lessons and new knowledge it has gathered from our conversation, it also removes stale or outdated information from that markdown file. I myself do not care what's written in that file, I steer, instruct and share my knowledge, visions, goal and preferences in our conversations, and the agent will boil that down and update the markdown folder. It has worked very well for me. I now do not have to worry about creating handoff prompts when creating a new conversation or that I have to teach an agent from the ground up about the context we're in, I just refer to that markdown file.
bravura
What if the memory were git repo backed, and the FTS5 were a speed-specific optimization? Then the memories could easily be human-reviewed. The repo would be the canonical source, and the FTS5 would be one specific materialization.
infogulch
Last month a Show HN: ContextVault proposed an interesting long-term memory architecture. I discussed the design with the founder: https://news.ycombinator.com/item?id=48900288#48901679 (I think he bailed the conversation when I got too close haha.) The basic shape is to periodically "distill the conversation into several areas (problem, solution, learnings, 'context' or original problem, plus other fields) and vectorized" (aka vector embedding), then queried against pgvector table to find related "memories". The vectorized distillates are also inserted into the pgvector table with a reference to back to the source conversation to add new memories. Vector search requires a full scan but it's still pretty fast and I bet it's more accurate the FTS.
0x500x79
I have a similar project that I have built and found great success with it storing things like coding standards, decisions, etc. One thing that is interesting during my work is that Codex and OpenCode using OpenAI models are REALLY good at using the tool, whereas new models and changes in Claude code keep making it difficult to stay on top of it's usability there. It seems like instructions and/or models are changing that cause for it to prefer the Claude Code memory tooling instead of allowing for remote memory tooling. Opus 5 seems to have made it materially worse (or some harness change around Opus 5, I haven't dug in entirely to analyze). I had to get more in-depth setup instructions to make sure that Claude Code would consistently use my memory tooling.