Your retrieval log is not an audit trail. I checked six Supermemory alternatives for one.

When an agent answers wrong, the first thing most of us open is the retrieval log. It returns a list of memory IDs that came back from the store. What it does not tell you is which of those survived ranking, which ones fitted inside the token budget, what their text said at that moment, or whether a policy rule dropped one before assembly.

Three weeks later it is worse. A compile job has rewritten some of those memories. Your log is now a list of pointers into content that has changed since the answer you are trying to explain.

I used that gap as the single axis for comparing open-source Supermemory alternatives, because every other axis is already covered by five other comparison posts. We build Statewave, one of the six below, so weigh that entry accordingly.

How the six compare on replay, before the detail

#	Tool	Storage	Can replay the assembled prompt	Main tradeoff
1	Statewave	Postgres + pgvector	Yes, signed receipts	No graph, no managed cloud
2	OpenViking	Your own infrastructure	No, read paths only	AGPL-3.0 server
3	Hindsight	Postgres or pg0	No, belief provenance instead	More model work
4	Mem0	Configurable vector store	No, you log it yourself	OSS and cloud feature lines
5	Graphiti	Neo4j, FalkorDB, Neptune	No, fact validity instead	You operate the graph
6	Letta	Memory blocks and MemFS	Partially, via versioning	Replaces the runtime

One of six documents the whole property as a first-class feature. Five give you a piece and leave you to build the rest, which is a fair trade when audit is not your constraint. The rest of this post is why each row says what it says.

Why teams run Supermemory before they go looking

Supermemory puts conversational memory, document retrieval, user profiles and local coding-agent memory behind one API, and the local edition is genuinely quick to prototype against. You point the SDK at localhost, change the base URL, and the same code runs against the cloud. For a team that wants one provider to own the whole context stack, that is a reasonable place to start, and most of the alternatives below do not match its document-handling range.

What the release notes say about the self-hosted cap

What sends people looking is rarely the API. It is the deployment line.

The supermemory-server 0.0.7 release notes state that self-hosted is licensed up to 10,000 documents, and that the cap is enforced at the API and shown at boot. Version 0.0.8 does not restate it. Supported self-hosting appears on the Scale plan at $399/month, and air-gapped deployment is listed only on Enterprise.

Two open issues are worth reading before you plan capacity. #1366 reports roughly 7 GB resident memory against a 2 GB store holding about 5,000 memories. #1413 describes full-database snapshots on a ten-second tick. Those are two bug reports from two environments rather than a benchmark, and I read them as a question to ask rather than a verdict.

Four properties that separate a log from an audit trail

"We log retrieval" is where most tools stop.

1. The assembled set, not the candidate set. What went into the prompt after ranking, truncation and policy, not what the store returned.
2. Immutable and addressable. It survives the next compile pass, and you can fetch it by ID in six months.
3. Tamper-evident. A hash over the bytes, so the record is worth something when someone disputes it.
4. Replayable. You can re-run assembly against the recorded inputs and see whether the behaviour changed. The minimum shape, concretely:

{
  "receipt_id": "01JB2K7W3Q8X5YPM4R6ZC9NTAE",
  "subject_id": "acct_8812",
  "task": "refund_status",
  "created_at": "2026-10-05T11:42:08Z",
  "budget": { "max_tokens": 4000, "used_tokens": 3117 },
  "included": [
    { "memory_id": "mem_01JAX...", "kind": "preference",
      "source_episode_ids": ["ep_01JAW..."], "tokens": 86, "rank": 1 }
  ],
  "excluded": [
    { "memory_id": "mem_01JAY...", "reason": "policy:deny:pii" },
    { "memory_id": "mem_01JAZ...", "reason": "budget" }
  ],
  "integrity": { "alg": "HMAC-SHA256", "digest": "9f2a..." }
}

That excluded array is the field people skip and the one that answers the actual postmortem question, which is usually why something the agent should have known never arrived.

The six alternatives, and what each one lets you reconstruct

1. Statewave, for replayable context on Postgres you already run

github.com/smaramwbc/statewave · Apache-2.0 · Postgres 14+ with pgvector, Python 3.11+

Interactions land as append-only episodes, and a compile step turns them into typed memories carrying confidence, validity and the source episode IDs they came from. Assembly runs ranked under a token budget, with a YAML policy of deny and redact rules over sensitivity labels evaluated first, in log_only or enforce mode. Each bundle emits a receipt with an HMAC-SHA256 signature and a replay endpoint.

• Reconstruct: all four properties above.
• Cost shape: your Postgres, plus LLM calls at compile time. ### 2. OpenViking, for document range Supermemory users actually miss

github.com/volcengine/OpenViking · AGPL-3.0 server

Context as a browsable filesystem under viking:// URIs, with a three-level read model so an agent pulls an abstract before it pulls full content. This is the strongest fit on the list where the job is document and multimodal range, which is the part of Supermemory nothing else here replaces.

• Reconstruct: the path an agent read is legible, which beats an ID list, though there is no signed record of an assembled prompt.
• Cost shape: your infrastructure, with a copyleft licence to clear with legal, or the licensed self-managed edition. ### 3. Hindsight, for agents that form beliefs rather than recall rows

github.com/vectorize-io/hindsight · MIT server · Postgres or embedded pg0

Separates facts and experiences from consolidated observations and mental models, with a reflect step that synthesises across them and four recall paths running in parallel. If you want an agent whose conclusions are evidence-backed rather than retrieved, nothing else here comes close.

• Reconstruct: observations trace to the experiences behind them, which is provenance for beliefs rather than for prompts.
• Cost shape: noticeably more model calls, since reflection is inference. ### 4. Mem0, for the memory API your team has probably already used

github.com/mem0ai/mem0 · Apache-2.0 core, managed platform alongside

The most familiar shape here: add, search, scope by user. Graph memory has been Platform-only since the v3 open-source SDK, so confirm which edition holds the feature you are switching for before you plan anything around it.

• Reconstruct: you get the memories a search returned and you log them yourself, which gives you a candidate set, not an assembled one.
• Cost shape: your vector store, plus extraction calls. ### 5. Graphiti, for time-aware facts between entities

github.com/getzep/graphiti · Apache-2.0 · Neo4j, FalkorDB or Amazon Neptune

A temporal knowledge graph with entities and relations, each carrying a validity interval, so you can ask what was true on a date. Nothing else here models time between entities as well. Graphiti ships as an engine rather than a service, so identity, auth, queueing, backups and the application API are yours to build.

• Reconstruct: edge validity gives you strong history of facts, with no record of prompts.
• Cost shape: a graph database you now operate. ### 6. Letta, for teams willing to adopt the whole runtime

docs.letta.com · agent runtime

Editable memory blocks and a transcript, plus a Git-backed memory filesystem, inside a full stateful agent runtime. Its memory design is the most opinionated of the six, and scope is the catch, because adopting it means adopting the runtime.

• Reconstruct: the memory filesystem is versioned, so you can read what a block said at a commit.
• Cost shape: replaces more of your stack than it adds to it. ## Where our own entry loses

Worth saying plainly, because this is the half of a vendor comparison that usually gets cut.

• No managed cloud. Someone on your team runs Postgres.
• No entity-relationship graph. Entities are extracted per memory, with no links between them and no traversal. If temporal reasoning between entities is the product, use Graphiti.
• No multimodal RAG. PDFs, media extraction, web crawling and large document corpora are exactly the part of Supermemory this does not replace, and OpenViking is the better answer there.
• Tenant scoping is enforced in the application, not by Postgres row-level security.
• The server is CI-tested on Linux only. If one of the other five does ship a documented replay path and I missed it in the docs, say so in the comments and I will correct the table.

Four questions that settle most of these evaluations

1. What is your unit of memory: a user, an account, a case, or a document? Decide that before you shortlist, because it removes half the list on its own.
2. When an answer is wrong, who has to explain it, and to whom? If the answer is "the engineer who wrote it", a log is fine and you can stop reading.
3. What is your deployment boundary, and does the free build reach it? Read the licence terms in the release notes rather than the badge on the repo.
4. What does the bill look like after the move? Self-hosting shifts cost from a per-document line to LLM extraction calls and someone's on-call rotation. It rarely removes it. Run your own conversations through two candidates in shadow mode and diff the assembled context before you switch reads. Code for the one I work on sits at github.com/smaramwbc/statewave if you would rather read the receipt implementation than take the table's word for it.

Pricing and repository details above were checked on 14 October 2026.