Memoid vs Supermemory: Open Infrastructure vs Managed Intelligence

Building AI agents that remember requires more than a vector database. You need extraction, versioning, temporal awareness, and graph context. Supermemory and Memoid both deliver this — but from opposite ends of the spectrum.

Supermemory is a cloud-native platform with a proprietary engine optimized for session-based memory intelligence. Memoid is an open, self-hostable API that runs everything in PostgreSQL. Here’s what that means in practice.

Architecture at a Glance

	Supermemory	Memoid
Storage	Custom vector graph engine	PostgreSQL + pgvector (unified)
Graph	Built into proprietary engine	PostgreSQL tables (built-in)
Extraction	Session-based chunking + LLM	Message-level LLM, per-request instructions
Search	Hybrid vector + keyword	Vector similarity + graph JOIN
Update strategy	Relational versioning	Additive with relations
Hosting	Cloud only	Cloud (self-hosted on Enterprise)
Temporal	Dual timestamps (document + event)	Dual timestamps (created + event)

1. Processing Philosophy

Supermemory: Session-Based Intelligence

Supermemory processes entire conversation sessions as units, not individual messages. This preserves context that message-level extraction loses — a reference to “that project we discussed” can be resolved within the session before facts are stored.

The platform stores everything, then organizes it with relationships. Intelligence is in retrieval, not ingestion.

Memoid: Message-Level with App Control

Memoid extracts facts from messages as they arrive. The app decides what to extract using per-request instructions:

client.add(
    messages=[{"role": "user", "content": "My wife Priya works at Infosys"}],
    user_id="user_123",
    instructions="Extract only facts about relationships and work.",
    extract_graph=True
)

This gives the app full control — different flows can extract different things from the same conversation. The trade-off: you don’t get the session-level context resolution that Supermemory provides.

2. Memory Versioning

Both platforms keep old memories when facts change — neither does destructive updates.

Supermemory

Maintains explicit relationships between memory versions:

• updates: New fact supersedes old (job change)
• extends: New fact adds detail (learning someone’s role)
• derives: New fact inferred from combining others

Memoid

Same model — both memories coexist with explicit relations stored in a memory_relations table:

"Mukesh works at Capex Labs" ──updates──→ "Mukesh works at Google"
"Priya is a PM at Infosys"  ──extends──→ "Priya is user's wife"

Apps can control this behavior per request via update_instructions.

3. Temporal Awareness

Both platforms solve the same problem: distinguishing when something happened from when it was stored.

Supermemory

Uses documentDate (when the conversation happened) and eventDate (when the referenced event happened). “I went to Goa last weekend” stores both the chat timestamp and the computed trip date.

Memoid

Uses created_at (when stored) and event_date (when the event happened). The LLM extracts temporal references automatically:

{
  "facts": [
    {"text": "User went to Goa", "event_date": "2026-03-22"}
  ]
}

Both approaches let agents reason about time — “What did the user do last month?” queries against event_date, not created_at.

4. Infrastructure

This is the biggest philosophical difference.

Supermemory: Managed Black Box

• Cloud-only — no self-hosting option
• Proprietary engine — you can’t inspect or modify internals
• No database management — everything is handled for you
• You trade control for convenience and sophistication

Memoid: Open PostgreSQL

• Cloud API with one PostgreSQL database behind it
• Enterprise plans include self-hosted deployment
• One connection string, one backup, one migration path
• You trade some sophistication for full control and transparency

5. Agent Context Retrieval

Supermemory

Single call for memories, but graph context may require additional queries depending on your use case.

Memoid

POST /v1/recall returns everything in one response:

{
  "memories": [
    {"memory": "Mukesh works at Capex Labs", "score": 0.92}
  ],
  "entities": [
    {"name": "Mukesh", "type": "person"},
    {"name": "Capex Labs", "type": "organization"}
  ],
  "relationships": [
    {"subject": "Mukesh", "predicate": "works_at", "object": "Capex Labs"}
  ]
}

GET /v1/context returns all memories and the full graph for a user — designed for UI visualization.

When to Use What

Choose Supermemory if:

• You want the most sophisticated memory intelligence out of the box
• Session-based processing fits your use case (chat apps, not API integrations)
• You don’t need to self-host or inspect internals
• Temporal reasoning is critical and you want it handled automatically
• You prefer managed infrastructure with no database ops

Choose Memoid if:

• You need self-hosting (available on Enterprise plan)
• You want full control over extraction rules per request
• You need to query your data directly with SQL
• You want one database for memories, vectors, and graph
• You’re building an API-first integration (not just chat)
• Regulatory or compliance requirements mandate data control

The Architecture Trade-off

The fundamental tension is between extraction intelligence and operational transparency.

Supermemory maximizes intelligence — session processing, relational versioning, temporal grounding — at the cost of being a black box you can’t self-host or inspect.

Memoid takes the position that PostgreSQL is enough. Vector search, graph queries, relational versioning, and temporal awareness all run in one database you fully control. The trade-off is that you won’t get Supermemory’s proprietary session intelligence. But for most agent memory use cases, explicit per-request instructions give you equivalent control over what gets stored and how.

The right choice depends on whether you prioritize managed intelligence or infrastructure transparency.

Related: Memoid vs Mem0