AI Memory Platform Comparison: Eleven Projects, Six Columns, Every Cell Sourced

On this page, 8 sections

LightRAG’s own README says its four default storage backends are in-memory databases with local file persistence, suitable only for small-scale testing, evaluation and debugging, and not suitable for production.

That sentence is in the project documentation, in bold, from the maintainers. It appears in almost no comparison of AI memory platforms, including the ones that put LightRAG at number one.

So this post is one table, eleven projects, six columns, and every cell traced to the document it came from. Star counts, licences and release dates come from the GitHub REST API on 3 September 2026.

Storage and retrieval details come from each project’s own README or documentation, read the same day. Nothing here came from memory, and you can re-run all of it.

How to read the columns

• Storage backend means the default you get when you configure nothing. Almost every project supports Postgres or Neo4j as an option. That tells you nothing. The default tells you what the maintainers expect you to run.
• Persistence means what survives a process restart, and where it physically lives.
• Retrieval means the primary mechanism that decides what comes back.
• Self-hostable means the project documents running it yourself without a hosted account.
• Licence is the SPDX identifier from the GitHub API, not the badge in the README.
• Last release is the published_at of the latest published release, which is not the same as the last commit. That gap is often the most informative number on the row.

The table

Project	Default storage backend	Persistence	Retrieval method	Self-hostable	Licence	Last release
mem0	Qdrant vector store	Vector store on disk	LLM extraction at write, then vector search over extracted memories	Yes	Apache-2.0	ts-v3.1.8, 2 Sep 2026
MemPalace	ChromaDB, embedded	Local palace directory	Verbatim storage, semantic search over local embeddings, scoped by wing and room	Yes	MIT	v3.9.0, 31 Aug 2026
Graphiti	Neo4j 5.26 or FalkorDB 1.1.2 or Neptune	Graph database you operate	Hybrid: embeddings, BM25 and graph traversal, facts carry validity windows	Yes	Apache-2.0	mcp-v1.1.0, 1 Sep 2026
Cognee	Ladybug/Kuzu graph plus LanceDB vectors, SQLite relational	Embedded stores on disk	Graph plus vector, ontology grounded	Yes	Apache-2.0	v1.5.3, 23 Aug 2026
LightRAG	JsonKVStorage, NanoVectorDBStorage, NetworkXStorage	Files under WORKING_DIR, dataset held in process memory	Dual-layer knowledge graph plus vector embeddings	Yes	MIT	v1.5.7, 2 Sep 2026
Basic Memory	Markdown files plus local SQLite index	Plain files on your disk	Full-text by default, optional hybrid vector with FastEmbed and optional reranking	Yes	AGPL-3.0	v0.23.2, 25 Aug 2026
Supermemory	Embedded graph engine, data in ./.supermemory	One local directory	Hybrid search over automatically extracted memories, scoped by container tag	Yes, one binary	MIT	server-v0.0.8, 17 Aug 2026
Khoj	pgvector/pgvector:pg15 via docker-compose	Postgres volume	Vector search over indexed documents	Yes, documented	AGPL-3.0	2.0.0-beta.28, 26 Mar 2026
codebase-memory-mcp	SQLite in ~/.cache/codebase-memory-mcp	SQLite, WAL mode, survives restart	openCypher subset, BM25 via FTS5, bundled nomic-embed-code vectors	Yes, no service to run	MIT	v0.10.8, 19 Aug 2026
Graphify	graph.json in graphify-out/	A JSON file in your working tree, 512 MiB cap	Graph traversal. No embeddings and no vector store by design	Yes, local by default	Apache-2.0	v0.9.53, 30 Aug 2026
Letta	See note below	See note below	See note below	Yes	Apache-2.0	0.16.8, 14 May 2026

Source for every cell

Taking them in the order they appear, with the document each claim came from.

• mem0. The README states mem0 requires a language model to function with gpt-5-mini as the default, and uses text-embedding-3-small as the default embedding model. The vector store overview at docs.mem0.ai/components/vectordbs/overview states that if no configuration is supplied, a default configuration is applied and Qdrant is used.
• MemPalace. The README states it stores conversation history as verbatim text, does not summarise, extract or paraphrase, and that the storage backend table lists chroma as the default with sqlite_exact, milvus, qdrant and pgvector as alternatives. Embeddings are local by default, around 30 MB for MiniLM or 300 MB for the multilingual option.
• Graphiti. The README lists Neo4j 5.26, FalkorDB 1.1.2, Amazon Neptune with OpenSearch Serverless, or Kuzu 0.11.2 which it marks deprecated because the upstream project is no longer maintained. It also states Graphiti defaults to OpenAI for inference and embedding and expects an OPENAI_API_KEY. Retrieval is described as combining semantic embeddings, keyword BM25 and graph traversal.
• Cognee. The README’s backend table gives Ladybug/Kuzu as the default graph store and LanceDB as the default vector store, with SQLite or Postgres always present as the shared relational database, and states that local development stays fully embedded with no extra services. Indexing requires LLM_API_KEY.
• LightRAG. The README names all four defaults explicitly: JsonKVStorage, NanoVectorDBStorage, NetworkXStorage and JsonDocStatusStorage, and its env.example sets exactly those. The same section says the whole dataset resides in the server process’s memory with files under WORKING_DIR serving only as persistence, so capacity is bounded by available RAM.
• Basic Memory. The README describes files plus a local SQLite index with no servers required, and lists semantic vector search with FastEmbed embeddings on SQLite or Postgres plus optional cross-encoder reranking as features you enable with environment variables.
• Supermemory. The README’s local section says first boot sets up an embedded graph engine and local embeddings, defaults to Xenova/bge-base-en-v1.5 with no API key, serves the full Memory API on localhost:6767, and keeps everything in a ./.supermemory directory. Scoping is by containerTag.
• Khoj. The self-hosting docs point at a docker-compose.yml in the repository. I pulled that file from the master branch and its database service is docker.io/pgvector/pgvector:pg15, alongside a SearXNG container and a sandbox container.
• codebase-memory-mcp. The README states SQLite databases stored at ~/.cache/codebase-memory-mcp/, persisting across restarts in WAL mode, resettable by deleting the directory, with CBM_CACHE_DIR as the override. It documents a read-only openCypher subset, BM25 through SQLite FTS5, and a semantic_query tool backed by nomic-embed-code embeddings compiled into the binary.
• Graphify. The README states the output is graph.html, GRAPH_REPORT.md and graph.json in graphify-out/, that it is not a vector index and uses no embeddings and no vector store, and that GRAPHIFY_MAX_GRAPH_BYTES overrides a 512 MiB cap on graph.json.

The Letta row, and why it is a note instead of data

letta-ai/letta has 24,587 stars and appears in most comparisons in this category.

Its README is 1,942 bytes and states that the repository now serves as a landing page, that the current source lives in letta-ai/letta-code, and that the retired V1 server is preserved on an archive branch which is unsupported, receives no fixes or security updates, and should not be used in production.

The live project is letta-code

So the row you would fill in from that repository describes software the maintainers have told you not to run. The live project is letta-ai/letta-code:

3,190 stars, Apache-2.0, TypeScript, last release v0.31.11 on 1 September 2026, installed with npm install -g @letta-ai/letta-code. Both figures from the GitHub API on 3 September 2026.

Why the row stays in, with a pointer

I have left the row in with a pointer rather than deleting it, because deleting it is how the mistake propagates.

If you see Letta in a comparison table with a storage backend listed and no note, the author did not open the repository.

Four things the table says that the marketing does not

1. A release date and a push date are different numbers

Khoj’s repository was pushed to on 2 August 2026. Its latest published GitHub release is 2.0.0-beta.28 from 26 March 2026. That is five months of active development with nothing tagged for release.

It is not abandonment, and it does mean that installing from a release gets you something quite old, while installing from master gets you something untagged.

R=khoj-ai/khoj
curl -s https://api.github.com/repos/$R | python3 -c "import json,sys;print(json.load(sys.stdin)['pushed_at'])"
curl -s https://api.github.com/repos/$R/releases/latest | python3 -c "import json,sys;print(json.load(sys.stdin)['published_at'])"
# run this on any project before you trust a maintenance claim

2. Self-hostable is a spectrum, not a checkbox

Every project in that table answers yes.

Behind the yes, the range runs from a single static binary with no runtime at one end to a Neo4j cluster plus an OpenAI key at the other. codebase-memory-mcp and Supermemory each ship a binary.

Basic Memory needs Python and writes files. Khoj brings up four containers.

Graphiti wants a graph database you keep alive. Those are four different commitments wearing one word. I costed what the heavier end looks like as a monthly bill in the breakdown of what self-hosted AI memory costs to run.

3. Licence matters more here than in most categories

Three licences appear: MIT, Apache-2.0 and AGPL-3.0. The AGPL entries are Basic Memory and Khoj.

AGPL-3.0 carries a network-use clause, which is a real consideration if you intend to offer the memory layer to your own users over a network as part of a product.

For personal or internal use it changes nothing. This is not legal advice, and it is the one column where reading the actual LICENSE file rather than a badge is worth ten minutes.

4. Two projects here refuse embeddings on principle, and both are code tools

Graphify says it plainly: not a vector index, no embeddings, no vector store. codebase-memory-mcp uses vectors only for one optional tool and compiles the model into the binary so there is no service.

Both are indexing code, where the structure is already explicit in the source and an embedding would be throwing that away.

Every project in the table that indexes conversations uses embeddings, because conversations have no such structure. That is the actual dividing line in this field, and I walked through both code tools in detail in the codebase-memory-mcp and Graphify comparison.

What this table cannot tell you

Retrieval quality

Every project publishes benchmark numbers and every set is vendor-run on a harness the vendor chose. Graphify discloses more of its method than most, naming its judge agreement rate. That is better practice and it is still self-scored.

Two systems can report near-identical numbers on a benchmark with the same name while measuring different quantities, which I went through in the mem0 and MemPalace benchmark comparison.

Whether you need a memory platform at all

It also cannot tell you whether you need a memory platform at all rather than retrieval over your documents, which is a question about architecture and protocol that I unpicked in the piece on MCP servers versus RAG.

If the constraint pushing you off a specific tool is its mandatory model key, the replacements are in the Cognee alternatives breakdown, and the whole cluster sits under the AI memory tools comparison.

One thing to do in the next ten minutes

Take whichever of these eleven you are closest to adopting, open its README, and search it for the word ‘production’. LightRAG will tell you its defaults are not for production.

Cognee will tell you its Postgres graph store is a demo feature. Graphiti will tell you Kuzu is deprecated. Those sentences are in the documentation and almost never in the comparison posts, mine included until I went and looked.

Resources

• GitHub REST API: repositories – source of every licence, star and push date above
• GitHub REST API: releases – source of every release date above
• LightRAG on GitHub – the default storage warning is in the Features section
• mem0 on GitHub and its vector store docs
• MemPalace on GitHub – storage backend table
• Graphiti on GitHub – graph database versions and the Kuzu deprecation
• Cognee on GitHub – backend defaults table
• Basic Memory on GitHub
• letta-ai/letta-code – the live Letta source
• Cognee: Knowledge Engine for AI Agent Memory on the cognee channel – a short walkthrough of the graph plus vector approach from the maintainers
• SPDX licence list – for reading the licence column properly

More on AI memory

• AI Memory for Writers: What Survives the Round Trip
• AI Memory With Tagging: Tags, Embeddings and Graph Edges Are Not Interchangeable