Supermemory returns scored hits.Statewave returns a traceable bundle.
Supermemory reranks scored search hits for recall. Statewave assembles a deterministic, traceable bundle every call.
Reranked for recall, or assembled for proof
Supermemory extracts memories into a graph and answers search with hybrid retrieval plus a reranker. Statewave compiles typed memories and assembles a ranked bundle the same way on every call.
Retrieval rides on a reranker
Hybrid search plus a context-aware reranker surface the most relevant hits, fast, at sub-300ms at scale. You get scored passages and an extracted profile; the score is a similarity rank, and ordering can shift as the index and reranker evolve.
Assembly is deterministic and inspectable
Given the same subject, task, token budget, and point in time, the assembler returns the identical bundle every run. Four signals set the order: kind priority, recency, task relevance, and temporal validity.
Where each capability lives
Both self-host on Postgres and are open-source. They diverge on what comes back, scored hits from a reranker, or a deterministic bundle you can inspect and govern.
What comes back
- sm
- Scored search hits, passages ranked by relevance
- S
- A ranked bundle of typed rows with per-memory metadata
How context is selected
- sm
- Hybrid vector + keyword search with a context-aware reranker
- S
- Deterministic assembly, ranked to a token budget
Same query, same result
- sm
- Reranked; ordering can shift as index state evolves
- S
- Byte-identical bundle every run
Retrieval latency
- sm
- Tuned for speed, sub-300ms at scale (vendor figure)
- S
- Single Postgres query; not independently latency-benchmarked here
Inspectable retrieval
- sm
- Passages with similarity scores; profile extracted separately
- S
- Explicit kind, confidence, valid_from/to per row
Provenance
- sm
- Results trace to source documents
- S
- source_episode_ids per memory; immutable episode chain
Read-path policy / receipts
- sm
- Not a core primitive of the public API
- S
- Policy engine + optional immutable, hash-chained receipt per call
Subject deletion (GDPR)
- sm
- Delete documents and memories via the API
- S
- One call hard-deletes a subject’s episodes and memories
Memory model
- sm
- Graph engine plus extracted user profiles
- S
- Typed memories (4 kinds) plus immutable episodes
Storage
- sm
- Self-host binary (embedded engine); hosted platform on Cloudflare edge
- S
- Postgres and pgvector, no proprietary store
Deployment
- sm
- Self-hostable binary and a managed hosted platform with connectors and MCP
- S
- Self-hosted only
Best for
- sm
- Fast, high-recall retrieval over large mixed corpora
- S
- Eval-driven, inspectable, deterministic retrieval with governance
Supermemory is an open-source memory and context engine with a self-hostable binary and a managed hosted platform; retrieval is hybrid vector-plus-keyword search with context-aware reranking. Rows reflect each product's public docs as of August 2026; verify self-hosted vs. hosted-platform feature parity before procurement.
Latency and recall over large, mixed corpora are the priority, chats, documents, and app events ingested and searched under 300ms. You want a managed platform with connectors and MCP out of the box, an extracted user profile and memory graph, and you're comfortable with reranked results rather than a fixed, byte-identical ordering.
Determinism is part of the contract, retrieval must be inspectable row by row, and every context call needs provenance back to its source episodes, with an optional immutable receipt and read-path policy enforcement. Eval-driven teams that grade end-to-end answer accuracy, not just retrieval recall, live here.
"Why did the agent say that?"
An agent states a fact about a returning customer. The same history runs through each system: one returns scored passages, the other a provenance chain plus a receipt.
Every call can leave a receipt
Supermemory returns scored search results from an extracted profile graph. Statewave governs assembly on the read path and can emit an immutable, provenance-traced receipt, in the Apache 2.0 core.
Two teams, two scoreboards
Both publish benchmarks, but different things. Statewave reports end-to-end QA accuracy; Supermemory reports retrieval precision, recall, and latency, shown apart, not stacked into one winner bar.
Read these apart, not against each other. A retrieval metric, Precision@1 or Recall@k, measures whether the right passage was fetched. An end-to-end QA-accuracy metric measures whether the agent's final answer was correct, and depends on the answerer model and the judge. Different metrics, different answerer models, different sample sizes. A direct "0.905 vs 59.7%" comparison would be meaningless.
Source: smaramwbc/statewave-memory-benchmarks README · server/api/memories.py.
Retrieval precision, recall, and speed, as published by Supermemory. Hybrid search plus a context-aware reranker; ordering can shift with index state. supermemory.ai/research/longmembench
Source: supermemory.ai and github.com/supermemoryai/supermemory, checked 2026-08-19. Figures are Supermemory's own; conditions differ from Statewave's harness.
Moving from Supermemory to Statewave
Documents become episodes, search becomes context. Plan a parallel-run period; the cutover is typically read-then-write, not a flag flip.
Supermemory's extracted user profile maps onto Statewave's profile_fact memories; free-form documents land as episodes and are compiled into typed memories. If you rely on Supermemory's memory-graph visualization or sub-300ms hosted latency, benchmark Statewave on your own corpus before committing.
FAQ
Frequently asked
Straight answers, not marketing lines.
How is Statewave different from Supermemory?
Supermemory ingests documents and chats, extracts memories into a graph with user profiles, and answers search with hybrid retrieval and a reranker, tuned for recall and speed. Statewave compiles typed memories with confidence and validity, ranks them to a token budget, and returns a deterministic bundle with read-path governance and optional receipts.
Can I compare Statewave’s 0.905 against Supermemory’s 59.7%?
No, they measure different things. Statewave’s 0.905 is end-to-end QA answer accuracy on LoCoMo; Supermemory’s 59.7% is Precision@1, a retrieval metric. Different metrics, different sample sizes. Read each on its own terms, and benchmark both on your own workload.
Isn’t Supermemory also open-source and self-hostable?
Yes, but the two binaries ask different things of you. Supermemory’s self-hosted binary is zero-config, an embedded graph engine with local embeddings and no database to provision. Statewave’s self-hosted core asks you to run Postgres and pgvector. The read path also differs: deterministic, provenance-traced assembly with receipts, versus fast, recall-tuned reranked search with an extracted profile.
Which one is faster?
Supermemory is engineered for speed and publishes sub-300ms retrieval at scale. Statewave doesn’t headline a latency number; its read path is a single Postgres query, designed around determinism rather than raw throughput.
What makes Statewave retrieval deterministic?
Four ranking signals, kind priority, recency, task relevance, and temporal validity, combine to a fixed token budget. The same subject, task, and point in time always produce the same bytes.
Does it work with Claude, Cursor, or Codex?
Yes. One command boots the runtime, and its shipped MCP server connects any MCP-compatible client. Supermemory’s hosted platform also ships MCP and connectors; Statewave is self-hosted, so you operate Postgres and a container.
Can I run it fully offline?
Yes. Statewave’s storage is Postgres plus pgvector, self-hosted with no cloud dependency. Supermemory’s local binary also runs standalone, but its managed platform is a Cloudflare-edge service.
Give your agent context it can prove
Self-host the Apache 2.0 runtime, wire it to your MCP client, and every context call can return a receipt.