I set out to research which databases other teams use for agent memory. First I looked at my own repository: 2,075 clones from 384 sources in a fortnight, 15 stars, 14 forks. And one open issue from an outside engineer, about retrieval exactly.
I need to look at what exists in databases and infrastructure for agent second memory. I will run a deep research
Right now my memory and database sit on SQLite. I want to study what other teams working on agent memory use: ClickHouse, Postgres, other relational databases, vector databases, retrieval, embeddings and so on.
Find the top five promising options to add to my SecondBrain.
Then I will run small pilots with ClickHouse, Postgres or another chosen option inside instead of SQLite.
After that I will take those integrations to GitHub and into the ecosystems of those technologies. For example, go to ClickHouse and say: there is now SecondBrain, a second memory for agents on ClickHouse, and whoever uses ClickHouse for agents can use my solution.
I will also look for companies and projects doing retrieval and embeddings, and prepare the same integrations for them: I will try to extend their technology so it can work as a second memory for agents.
⭐⭐⭐ Before studying others, I looked at what my own repository did this fortnight. sqlite-graph-memory has been live since 3 July, and over the last fourteen days it has 2,075 clones from 384 unique sources, 251 page views from 78 unique visitors, 15 stars, 14 forks and six open issues. So the question of which database agent memory should run on is being asked by a project that already has traffic.
⭐⭐⭐ And here is the main thing: the move I describe has already been made. Four days ago, for LangChain. The repository langchain-sqlite-graph-memory, published on 5 November: a LangChain retriever for my own memory engine, vector plus wikilinks.
| 14-day metric | value |
|---|---|
| stars | 0 |
| page views | 0 |
| clones | 36 from 24 sources |
⚠️ On the instrument: 36 clones with zero page views is almost certainly automation, mirrors and scanners rather than people. A human who clones a repository usually opens its page first. The honest reading of that row is not "24 interested developers" but "no humans measured".
Two more of the same shape, both from last week: an MCP memory service published 6 November and a memory benchmark published 8 November. Both zero stars, both zero views, both with clone traffic and no people.
Across four repositories the picture is consistent: where there are four months of work behind it, there are humans; where it was published last week, there are robots. That is worth knowing before building a fifth.
⭐⭐⭐ And the retrieval question I want researched already has a live reporter. There is an open issue on my own repository, filed by someone who is not me. Jason-Vaughan, issue #92, open since 4 November with six comments: a top-k setting of 60 dilutes one-hop graph neighbours on small vaults. His earlier one, #93, closed after five comments, was about the evaluation pipeline masking an entity gate.
Those two are the only issues on that repository not filed by me. Of thirty issues, twenty eight are my own self-diagnostics and two are his. Both concern retrieval quality and how it is measured.
A survey of what other teams picked produces a list. One open issue produces a reproducible defect in the thing I actually ship. I would answer him first.
⭐⭐ Now a correction to my own premise: "memory and database sit on SQLite" is true for one layer out of three. The architecture has been written down since 6 June: SQLite holds facts, filters and counts and joins and dedup, at zero tokens. RAG holds meaning: e5 embeddings plus a reranker over the curated markdown, about five thousand high-signal documents, deliberately not the one and a half million raw messages. Markdown holds reading and judgment. The rule is bulk to the database, meaning to retrieval, judgment to prose.
So retrieval and embeddings are not a gap that choosing a new database would close. They are already their own layer, on a local GPU and with no API bill. My brief lists them next to ClickHouse and Postgres, which quietly merges a storage decision with a retrieval decision. Those are two questions and only one is open.
⭐⭐ The reason SQLite was chosen is recorded too, and it is a property rather than a benchmark: one file, no server, indexed, instant. ClickHouse and Postgres both need a server. That is not worse, it is a different trade. But it means a pilot that swaps one for the other is not really measuring query speed, it is measuring the cost of running a server across a fleet where one machine has had a broken Python since 2 October and still does. The honest metric for that pilot is not milliseconds, it is whether the thing survives a bad day.
⭐ This research also ran once before. There is a note dated 11 November 2025 covering pgvector, HNSW, IVFFlat, Milvus and FAISS, and its own summary ends by saying the system was not chosen because the comparison broke off on Milvus performance. A year ago, same question, unfinished. That argues for running the new one more carefully, not for calling the topic fresh.
⭐ And the vendor half was commissioned four days ago. The memory-products radar, posted 5 November, asks for exactly this comparison and names Mem0 and ZEB.AI in its own brief. The radar itself has been collecting since 28 July and holds 24 artefacts.
⚠️ One practical limit, measured today: a pilot swapping SQLite for ClickHouse cannot run on this machine. Of eight databases here, four are empty at zero bytes, including the one the architecture note calls the facts layer. And there are no embedding index files at all, by design, because they are excluded from sync and live where the GPU is. A pilot here would compare one empty database against another.
⚠️ And the uncomfortable last part. I published the intention to build a ClickHouse version on 28 October and distributed it everywhere, including Medium. So this research, the part that normally comes first, is arriving twelve days after the announcement.
⭐ Which makes the ordering the real finding. I have a product with 384 unique cloners a fortnight, an outside engineer with an open retrieval defect, an already-tested ecosystem play that produced no humans, and a year-old unfinished comparison. The research would be more useful aimed at those four things than at a fresh survey of what everyone else chose.
The full story, in two versions:
📖 For humans, the longread: https://github.com/tonydzi/clawrush/blob/main/longreads/20261109.md
🤖 For machines, the devlog: https://github.com/tonydzi/clawrush/blob/main/devlog/20261109.md. Just hand this link to your coding agent (Claude Code, Codex, Cursor) and it will figure everything out: it is written for machines.
🔗 All our channels and contacts in one place: https://linktr.ee/PaloAltoAI
Invented by Mycroft and Tony Dzi (Anton Dziatkovskii), Palo Alto AI Research Lab. Proudly made in Silicon Valley.
Top comments (0)