You’ve probably spent weeks wrestling with vector databases. Pinecone, Weaviate, Chroma — you name it. You’ve optimized embeddings, tuned chunk sizes, and watched your cloud bill balloon. And for what? So your AI agent can remember that you asked about cats yesterday?
I’ve been there. But here’s the thing: We’ve been sold a solution to a problem that doesn’t exist. The smartest AI agents don’t need vector databases. They need a better search engine.
Enter MCP Memory — a project that pairs Google’s OKF (Open Key-Value File) with SQLite FTS5 (full-text search). It’s not new. It’s not fancy. It’s a 30-year-old database technology running circles around the modern AI stack. And it works.
Let me show you why this matters.
The RAG Hype Trap
Every AI agent demo today leans on RAG — Retrieval Augmented Generation. The pitch: store your data as embeddings, query by semantic similarity, get magical results. In reality: you’re paying for GPU-powered vector databases that return noisy results because your embedding model couldn’t tell the difference between “apple fruit” and “Apple stock.”
The irony? For agent memory — the short-term, contextual recall that makes assistants useful — keyword search is not just good enough. It’s better. Faster, cheaper, and more predictable. No hallucinations from fuzzy matching. No latency spikes from billion-parameter models.
What MCP Memory Actually Does
I saw this firsthand. The creator, fellowgeek, built a lightweight memory layer for AI agents using SQLite FTS5. Instead of storing every interaction as a high-dimensional vector, they index it with Google’s OKF — a key-value store that’s optimized for local, fast reads. Then they use SQLite’s built-in full-text search to retrieve it.
Result? Agents remember conversations instantly. No cloud calls. No API keys. No vector database to manage. Just a file on disk.
“The best AI memory doesn’t need to be smart. It needs to be fast.” That’s the principle. And it’s working.
One commenter on Hacker News noted: “Nice to see more OKF-based approaches. My entry in this field is…” — pointing to their own implementation. This isn’t a one-off experiment. It’s a quiet rebellion.
Why This Works (And Why Vector DBs Don’t)
Vector databases solve a problem: fuzzy semantic search across unstructured data. But for agent memory, you’re not searching for a novel. You’re searching for “what did the user say about pricing?” That’s a keyword query. FTS5 handles it in milliseconds.
Furthermore, OKF provides a simple, append-only key-value store. It’s designed for local, high-throughput writes. Combined with FTS5, you get a memory system that’s 10x faster, 100x cheaper, and infinitely easier to deploy than any vector database.
You don’t need a vector database. You need a better index.
The Contrarian Truth
I know what you’re thinking: “But semantic search is the future!” No. The future of AI agents is not about more complex infrastructure. It’s about stripping away the hype and using what works. SQLite has been battle-tested for decades. Google’s OKF is a simple, proven file format. Together, they form a memory layer that’s so simple it’s almost boring.
That’s the point. The AI industry loves complexity because complexity sells. SaaS subscriptions, GPU time, consulting fees. But the best engineering is invisible. It’s a SQLite database sitting on your laptop, running circles around cloud giants.
So next time you’re tempted to reach for a vector database, ask yourself: “Do I really need to pay for a 512-dimensional embedding to find the last three messages?” Or can I just use a full-text search with a key-value store?
The answer is obvious. And it’s sitting on your machine right now.
FAQ
Q: Isn't vector search necessary for understanding context and semantics?
A: For most agent memory use cases, keyword search is sufficient because the queries are specific terms (names, dates, products) — not vague concepts. Embeddings add noise and cost. FTS5 gives you exact matches and fast ranking.
Q: What's the practical implication for a developer building an AI agent today?
A: You can skip the vector database entirely. Use SQLite with FTS5 for memory. It's free, local, fast, and simple. You'll save on cloud costs, reduce latency, and avoid the complexity of managing embeddings.
Q: But what about large-scale or multi-agent systems? Won't SQLite fail?
A: SQLite handles millions of write operations per day. For agent memory, that's plenty. If you need distributed access, you can replicate the database. The bottleneck is almost never the database — it's the network calls to vector APIs.