BrainDB: Karpathy's 'LLM wiki' idea, but as a real DB with typed entities and a graph
Posted by dimknaf@reddit | LocalLLaMA | View on Reddit | 11 comments
Why BrainDB?
Inspired by Karpathy's LLM wiki idea — give an LLM a persistent external memory it can read and write. BrainDB takes that further by adding structure, retrieval, and a graph on top of the "plain markdown files" baseline.
- vs. RAG. RAG is stateless: embed documents, retrieve similar chunks on every query, stuff them into context. There's no notion of an entity that persists, accrues connections, or ages. BrainDB stores typed entities (thoughts, facts, sources, documents, rules) with explicit
supports/contradicts/elaborates/derived_from/similar_torelations, combined fuzzy + semantic search, graph traversal up to 3 hops, and temporal decay so stale items fade while accessed ones stay sharp. Retrieval returns a ranked graph neighbourhood, not a pile of chunks. - vs. classic graph DBs (Neo4j, Memgraph). Those are general-purpose graph stores with their own query languages and ops cost. BrainDB is purpose-built for LLM agents: a plain HTTP API designed for tool-calling, semantically meaningful fields (
certainty,importance,emotional_valence), built-in text + pgvector search with geometric-mean scoring, always-on rule injection, automatic provenance, and runs on plain PostgreSQL +pg_trgm+pgvector— no new infrastructure to operate. - vs. markdown files as memory. Markdown wikis are flat and unstructured: the LLM has to grep, read whole files into context, and manage linking by hand. BrainDB's entities are atomic, queryable, ranked, and self-connecting. Facts extracted from a document automatically link back to the source via
derived_from; recall returns relevant nodes plus their graph neighbourhood; nothing needs to be read in full unless the agent asks for it.
knlgeth@reddit
A terminal based of Karpathy's idea of LLM Knowledge Bases. Give it a spin and let me know what you think: https://github.com/atomicmemory/llm-wiki-compiler
riddlemewhat2@reddit
This feels like the natural next step. moving from markdown wikis to typed, queryable entities solves a lot of scaling and retrieval issues.
The tradeoff is complexity. you get better structure and recall, but you lose the simplicity and transparency of plain files.
If you want to compare with a lighter approach, this repo shows the markdown-first version of the same idea:
https://github.com/atomicmemory/llm-wiki-compiler
dimknaf@reddit (OP)
https://www.youtube.com/watch?v=dxq7WtWxi44 - This is also a good related video touching on the subject
croninsiglos@reddit
But now you need a layer to turn it back into plain text for the llm and you’re not saving that intermediate step.
The markdown wikis are not flat and unstructured if you read the original post and there are not linked by hand.
dimknaf@reddit (OP)
But did you really test it.
Maybe I should publish a video or a demo, as I believe very few people will bother really trying it. But with what I have tried so far, I am really impressed and I wanted to take this out to the world
croninsiglos@reddit
But that’s what the native llm wiki skill already does and it’s already been incorporated into every major agent harness.
dimknaf@reddit (OP)
markdown + git is simpler and I get this. The thing is LLM wiki has no embedding search and no typed relations. So for a question like "what did the nephew of that person know about X", grep kind of misses it and the LLM ends up opening a pile of files hoping to connect the dots.
BrainDB does that connecting on ingestion — facts auto link back to the source, embeddings catch fuzzy name matches grep misses, and you get a ranked graph neighbourhood back instead of raw files. For small narrative vaults markdown is totally enough, I agree. For messy relational stuff it made a real difference for me in my tests, and I guess the bigger the memory becomes the more important this becomes.
croninsiglos@reddit
It doesn’t need it though since it was entirely curated by the LLM itself based on previous queries. Don’t think of it like a replacement for RAG, but rather a caching memory layer.
Ok_Mammoth589@reddit
And the whole point, the underlying realization is that context is now big enough to have all this stuff directly in context, which is the best place to have it. The only reason you don't want it reading whole files at one time is because you can't afford Claude's astronomical prices
dimknaf@reddit (OP)
I do not think is efficiency only. It is also focus. If you have a clever mechine, do you want it really to ingest 500K of unrelated tokens, when you do not really need all this information? If every piece of the context matters yes (like sometimes in coding), but when the LLM is in search mode, the database is a much more workable solution. So you can keep the same principles of freedom, so the LLM does this, but structure really help, the same way that a knowledge worker would be helped to have a system than a list of doc files.
croninsiglos@reddit
It doesn’t need it though since it was entirely curated by the LLM itself based on previous queries. Don’t think of it like a replacement for RAG, but rather a caching memory layer.