Retrieval Logs ≠ Audit Trails: A Cross-Comparison of 6 Supermemory Alternatives

Title

Retrieval Logs ≠ Audit Trails: A Cross-Comparison of 6 Supermemory Alternatives

Meta Description

Retrieval logs give you the candidate set; audit trails require the assembled set. This article uses replayability as its sole axis to compare six open-source Supermemory alternatives — Statewave, OpenViking, Hindsight, Mem0, Graphiti, and Letta — and examines Supermemory's self-hosted document cap and licensing limits.

Article Content

When an Agent answers a question wrong, most people's first instinct is to open the retrieval logs. The logs return a pile of memory IDs recalled from storage, but they won't tell you: which IDs actually made it into context after ranking, which were truncated due to token budget, what the memory body text was at the time, or whether any policy rule kicked a memory out before assembly.

Three weeks later, things get worse. A compile job may have already rewritten some of the memories, turning your logs into a string of pointers to "changed content" with zero explanatory power. This gap is the sole axis for this cross-comparison of six open-source Supermemory alternatives — every other comparison dimension has been beaten to death.

Why Teams Start with Supermemory, Then Look for a Way Out

Supermemory rolls conversational memory, document retrieval, user profiles, and local coding Agent memory behind a single API. The local version is genuinely fast for prototype validation: point the SDK at localhost, change the base URL, and the same code runs in the cloud. For teams that want a single vendor to take over the entire context stack, this is a reasonable starting point — and its document-processing breadth is something most alternatives below can't match.

What actually drives people to look for alternatives is rarely the API — it's the deployment limits. According to the supermemory-server 0.0.7 release notes, the self-hosted version is licensed for a maximum of 10,000 documents, enforced at the API layer and displayed at startup; version 0.0.8 does not restate this limit. The official pricing page shows supported self-hosting appears in the $399/month Scale plan, with air-gapped deployment restricted to Enterprise. Two open issues are worth reading before planning capacity: #1366 reports roughly 5,000 memories and 2GB of storage consuming about 7GB of resident memory; #1413 describes a full-store snapshot every ten seconds. These are two bug reports from two environments, not benchmarks — treat them as a checklist of questions, not conclusions.

Four Properties That Separate Logs from Audit Trails

"We log retrieval" is where most tools stop. A real audit trail needs four things:

• It records the assembled set, not the candidate set: what actually entered the prompt after ranking, truncation, and policy filtering.
• It is immutable and addressable: it survives the next compile and can be retrieved by ID six months later.
• It is tamper-evident: bytes are hashed, so the record has value in a dispute.
• It is replayable: you can re-run assembly with the recorded inputs and see whether behavior changes.

A minimal receipt looks like this: it contains receipt_id, subject_id, task, created_at, token budget (max_tokens/used_tokens), an included array (with memory_id, kind, source episode, token count, and rank), an excluded array (with reasons such as policy:deny:pii or budget), and an integrity field (an HMAC-SHA256 digest).

The excluded array is the most frequently skipped field, yet it answers the most common post-mortem question — what people really want to know is usually "why didn't the Agent get the thing it should have known?"

HMAC-SHA256 is a message authentication code based on the SHA-256 hash function and a secret key, used to verify message integrity and authenticity. In an audit receipt, it doesn't simply hash the data — it computes a digest over the receipt content together with a key held only by the server. This means any byte-level change to a stored receipt causes a digest mismatch, and anyone without the key cannot forge a seemingly valid receipt. Compared to a plain hash, HMAC adds protection against malicious tampering, making it suitable as non-repudiable evidence in disputes. The trade-off is that key management becomes part of the security boundary: a leaked key means the receipt's tamper-evidence property is void.

Breaking Down the Six Options

1. Statewave: Replayable Context on Your Own Postgres

Apache-2.0 license, requiring Postgres 14+ with pgvector and Python 3.11+. Interactions land as append-only episodes, and a compile step turns them into typed memories with confidence, validity periods, and source episode IDs. Assembly ranks under a token budget, and YAML policies evaluate deny and redact rules first (supporting log_only and enforce modes). Each bundle emits an HMAC-SHA256-signed receipt and exposes a replay endpoint.

All four properties above can be reconstructed. The cost is bringing your own Postgres, plus LLM calls at compile time.

2. OpenViking: Filling the Document Breadth Supermemory Users Actually Miss

AGPL-3.0 server. Context is organized as a browsable filesystem under viking:// URIs, with a three-tier read model that lets the Agent pull a summary before fetching full text. Its document and multimodal breadth is the strongest on this list — exactly what other Supermemory alternatives can't fill in. It makes the Agent's read path legible — better than a string of IDs — but it has no signed record of the assembled prompt. The cost is bringing your own infrastructure, plus having legal confirm the copyleft license or choosing a licensed self-managed version.

3. Hindsight: Built for Agents That "Form Beliefs" Rather Than "Recall Rows"

MIT server, running on Postgres or embedded pg0. It separates facts and experiences from consolidated observations and mental models; a reflect step synthesizes across layers, and four recall paths run in parallel. If you want an Agent whose conclusions are evidence-backed rather than simply retrieved, nothing on this list comes closer. What's reconstructable is observation traced back to the experiences behind it — belief-oriented provenance, not prompt-oriented tracing. The cost is noticeably more model calls, because reflection is itself reasoning.

4. Mem0: The Memory API Your Team Has Probably Already Used

The core is Apache-2.0, with a separate hosted platform. The most familiar shape: add, search, scoped per user. Since the v3 open-source SDK, graph memory is limited to the Platform version — verify which version a target feature falls under before migrating. What it gives you is the memories returned by search; you have to log things yourself — you get the candidate set, not the assembled set. The cost is bringing your own vector store, plus extraction calls.

5. Graphiti: Time-Aware Facts Between Entities

Apache-2.0, supporting Neo4j, FalkorDB, or Amazon Neptune. A temporal knowledge graph where entities and relationships each carry validity intervals, so you can ask "what was true on a given date." Its temporal modeling between entities is unmatched. It ships as an engine rather than a service — identity, auth, queues, backups, and the application API are all yours to build. What's reconstructable is edge validity — powerful fact history, but no prompt records. The cost is operating a graph database.

6. Letta: For Teams Willing to Adopt the Entire Runtime

Editable memory blocks and conversation records, plus a Git-versioned memory filesystem, all inside a stateful Agent runtime. Its memory design is the most radical of the six, and the cost is in scope: adopting it means adopting its runtime. The memory filesystem is versioned, so you can read what a block looked like at a given commit. Partially reconstructable, but it replaces more of your stack than it adds.

pgvector is an open-source extension for PostgreSQL that adds a vector data type, approximate nearest-neighbor indexes (such as IVFFlat, HNSW), and distance operators. It lets Postgres — originally relational-data-only — store and retrieve embedding vectors directly, combining vector search with transactions, row-level security, backups, and other database capabilities in a single system. Statewave's dependence on Postgres 14+ and pgvector means memory storage and vector recall can happen within the same database instance, reducing the operational complexity and data-sync problems of a separate vector database. The trade-off is that vector index scale limits and performance tuning are still constrained by Postgres itself; very large corpora typically require a dedicated vector database.

The Shortcomings of Our Own Solution

Since this is the half that usually gets cut from vendor comparisons, let's be direct. Statewave has no managed cloud — someone has to operate Postgres; no entity relationship graph — entities are extracted per memory, unconnected and non-traversable — if your product is fundamentally about temporal reasoning between entities, choose Graphiti; no multimodal RAG — PDF, media extraction, web crawling, and large-scale document corpora are precisely what it can't replace Supermemory for, where OpenViking is the better fit; tenant isolation is at the application layer rather than Postgres row-level security; and the server has only been CI-tested on Linux.

Four Questions That Decide Most of the Evaluation

First, what is the unit of memory: user, account, case, or document? Settle this first and the list automatically halves. Second, when something goes wrong, who explains it, and to whom? If the answer is "the engineer who wrote the code," logs are enough — you can close this article. Third, where are the deployment boundaries, and can a free build reach them? Read the licensing terms in the release notes, not just the repo badges. Fourth, what does the bill look like after migration? Self-hosting swaps per-document billing for LLM extraction calls plus someone's on-call schedule — costs rarely disappear.

Before switching read paths, run your own conversations through two candidate options in shadow mode and diff the context they assemble.

One-line Summary

A cross-comparison of six open-source Supermemory alternatives, focused on audit trails and replayable context.

Paragraph Summary

The article evaluates six open-source Supermemory alternatives using audit trails as its sole comparison axis. It first notes that retrieval logs only return recalled IDs, failing to explain ranking, token-budget truncation, policy filtering, and original body text — and that logs become useless after compile rewrites. It then proposes four properties of an audit trail: recording the assembled set, immutability and addressability, tamper-evident hashing, and replayability, along with a minimal receipt structure. It then analyzes the architecture, reconstructable properties, and costs of Statewave, OpenViking, Hindsight, Mem0, Graphiti, and Letta — of which only Statewave natively supports signed receipts and assembled-prompt replay. The author candidly notes Statewave's shortcomings in managed cloud, entity relationship graphs, and multimodal RAG, closing with four evaluation questions.