MemorySync vs Supermemory
A sourced comparison of MemorySync and Supermemory: what each stores, how memories update and are forgotten, isolation, published latency, compliance, events, deployment and pricing.
Capabilities side by side
| Capability | MemorySync | Supermemory |
|---|---|---|
| What a write stores | Facts extracted from the text; a new value for a one-value fact, such as a city or a job title, replaces the old one | Document chunks for retrieval, plus facts extracted asynchronously after the document is indexed |
| How memories change | Typed links between related memories, such as supports, contradiction and extends | Each new fact updates, extends or derives from older ones; expired, contradicted and noisy facts are forgotten automatically; a profile per container tag |
| Scoping | End user required on every API-key call (400 without it); every read, search and delete is filtered to that end user and project | A containerTag per user or project, each in its own vector namespace; keys and members can be limited to tags, and with an unrestricted key the tag is optional on search |
| Read latency | 179 ms p50 / 980 ms p95 server-side, measured against production | Search: 187 ms server time and 356 ms end to end, published by Supermemory from production traffic |
| Identity & access | SAML 2.0, OIDC and SCIM 2.0 on every plan, including Free | SSO on the Enterprise plan; SAML and SCIM are not documented |
| Compliance | Audit logs on every plan; retention policies issue deletion receipts, and tombstones keep deleted memories from coming back | SOC 2 Type II and GDPR; HIPAA BAA on Scale and Enterprise; document deletes are permanent, while forgetting a memory is a soft delete |
| Webhooks | Memory, import, team, API-key, billing and rate-limit events | No outbound webhooks are documented; processing status is polled with GET /v3/documents/{id} |
| Files & connectors | POST /memory/upload extracts facts from PDF, DOCX, PPTX, spreadsheets, HTML and more; connectors for Google Drive, OneDrive, Notion, GitHub, Slack, Granola, Amazon S3 and a web crawler | Files up to 50 MB and URLs, chunked for retrieval; connectors for Google Drive, OneDrive, Notion, Gmail, GitHub, Granola, S3 and a web crawler, by plan |
| SDKs & MCP | Python and TypeScript SDKs, CLIs on npm and PyPI, hosted MCP server | TypeScript and Python SDKs, REST with OpenAPI, hosted MCP server |
| Deployment | Managed service only | Managed API; a self-hosted binary that uses your own models; supported self-hosting on Scale and Enterprise, air-gapped on Enterprise |
| Pricing | Free: 10,000 adds and 1,000 retrievals a month. Starter $29, Pro $179, Scale $349 a month | Free: $5 of credits a month. Pro $19, Max $100, Scale $399 a month; Enterprise custom |
The Supermemory column states only what Supermemory publishes about itself, checked on 29 September 2026. Sources: Pricing · Homepage (latency) · How it works · Graph memory · Container tags · Adding content · Memory operations · Security · Billing and plans · Self-hosting · MCP server. MemorySync figures come from our own production measurements and documentation. Capability tables age quickly: if anything here is out of date, tell us at team@memorysync.io and we will correct it.
Why teams choose MemorySync
- Built for B2B multi-tenant SaaS: every call is scoped to an organization, project and end user.
- Governance on every plan: audit logs, and deletion receipts for retention-policy deletions.
- SAML, OIDC and SCIM on every plan, and roles and permissions for team members.
- Webhooks for memory, import, team, API-key and billing events, so your systems hear about changes instead of polling.
Moving from Supermemory
- 1
Run memorysync migrate supermemory --key $SUPERMEMORY_API_KEY --dry-run, or pass an export with --file, to see which end user each document would land under.
- 2
Container tags that start with user_ become the end user, and every other tag stays a tag. Pass --scope-tag-prefix if your convention differs.
- 3
Run it again without --dry-run. Each document is extracted into facts under its end user, with its Supermemory id sent as client_ref, so a re-run skips what already moved.
- 4
Replace search calls with a MemorySync query for the end user.
Common questions
How does Supermemory’s architecture differ from MemorySync’s?
Supermemory keeps two things per container tag: document chunks for retrieval, and a graph of extracted facts that a second, asynchronous pass builds after a document is indexed. MemorySync keeps extracted facts only, stores them before POST /memory/add returns, and requires an end user on every API-key call.
Do both link related facts?
Yes, in different ways. Supermemory connects each new fact to older ones as an update, an extension or an inference, and forgets expired or contradicted facts. MemorySync links related memories with typed relationships, such as supports, contradiction and extends, and replaces a one-value fact, such as a city or a job title, when a new value arrives.
Comparisons
Move from Supermemory to MemorySync
Start on the free tier and evaluate retrieval, isolation, and governance against your own workload.
Start free. No credit card required.