Where memory lives
The substrate an agent actually persists memory to, grouped by storage class. Every row is first-party sourced from the vendor's own docs. Layers = the cognitive layer it serves. Retrieval = its primary access pattern.
Purpose-built memory layers: extraction, dedup and retrieval handled for you.
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| Mem0 | Semantic · Episodic · Working | LLM extracts salient facts at write-time, dedupes, stores in a hosted vector store scoped per user/agent/session | Write-time extraction + semantic | partial (open-core) | ↗ |
| Zep / Graphiti | Episodic · Semantic | Ingests messages into a bi-temporal knowledge graph with episodic nodes, extracted entities/facts and community summaries | Temporal KG query (time + semantic + graph) | partial (open-core) | ↗ |
| Letta (MemGPT) | Working · Episodic · Semantic · Procedural | Stateful agents with in-context core memory plus paged archival/recall memory the agent self-edits via tool calls | Agent-queried tool-call (memory paging) | partial (open-core) | ↗ |
| LangMem (LangChain) | Semantic · Episodic · Procedural | SDK extracts/updates memories over any LangGraph BaseStore; supports hot-path and background consolidation | Agent-queried tool-call + semantic | yes | ↗ |
| Cognee | Semantic · Episodic | ECL (Extract-Cognify-Load) pipeline turns documents/data into a self-hosted knowledge graph plus vectors | Graph + RAG / semantic | partial (open-core) | ↗ |
| Supermemory | Semantic · Episodic · Working | Hosted memory/context API extracts evolving user facts, handles temporal updates, builds a user profile as default LLM context | Write-time extraction + semantic | partial (open-core) | ↗ |
| MemU | Episodic · Semantic | Ingests multi-modal data and organizes it into a navigable tree of human-readable Markdown memory files | RAG + LLM retrieval | partial (open-core) | ↗ |
| Memobase | Semantic · Episodic | User-profile backend tracking structured profile slots plus an event timeline per user (FastAPI/Postgres/Redis) | Profile + timeline lookup | partial (open-core) | ↗ |
| Redis Agent Memory Server | Working · Semantic · Episodic | Splits working (session) vs long-term memory in Redis with configurable extraction; REST/MCP/Python interfaces | Hybrid semantic + keyword | yes | ↗ |
| Memary | Episodic · Semantic | Routes agent actions into a knowledge graph (Neo4j/FalkorDB) via a memory stream tracking recency/frequency | Recursive KG subgraph (multi-hop) | yes | ↗ |
The semantic-recall substrate: embed, similarity-search, inject (RAG).
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| Pinecone | Semantic (RAG) | Proprietary Rust ANN indexes; fully-managed serverless (or BYOC), no infra tuning | RAG / semantic | no | ↗ |
| Weaviate | Semantic (RAG) | HNSW vector index with built-in embeddings and hybrid search; self-host or managed Weaviate Cloud | RAG / semantic | yes | ↗ |
| Qdrant | Semantic (RAG) | Rust HNSW engine with rich payload filtering; self-host OSS or managed/hybrid Qdrant Cloud | RAG / semantic | yes | ↗ |
| Chroma | Semantic (RAG) | Developer-first embedding store (vector + BM25 + metadata); embedded OSS or serverless Chroma Cloud | RAG / semantic | yes | ↗ |
| Milvus (Zilliz) | Semantic (RAG) | Distributed engine with IVF/HNSW indexes scaling to billions of vectors; self-host or managed Zilliz Cloud | RAG / semantic | yes | ↗ |
| pgvector | Semantic (RAG) | Postgres extension adding HNSW and IVFFlat ANN indexes to existing Postgres; self-hosted anywhere | RAG / semantic | yes | ↗ |
| LanceDB | Semantic (RAG) | Embedded, filesystem-native DB on the open Lance format with IVF-PQ/HNSW; local OSS or LanceDB Cloud | RAG / semantic | partial (open-core) | ↗ |
| turbopuffer | Semantic (RAG) | Object-storage-native (S3) vector + BM25 search with SSD/memory cache tiers; managed SaaS | RAG / semantic | no | ↗ |
| Vespa | Semantic (RAG) | HNSW + native tensor engine for vector/text/structured at scale; self-host OSS or Vespa Cloud | RAG / semantic | yes | ↗ |
| MongoDB Atlas Vector Search | Semantic (RAG) | HNSW-based ANN built into the document DB (vectors beside operational data); fully-managed Atlas | RAG / semantic | partial (open-core) | ↗ |
| Redis (Vector Search) | Semantic (RAG) | In-memory vector index (HNSW or FLAT) via the Redis query engine; self-host or Redis Cloud | RAG / semantic | partial (open-core) | ↗ |
| Elasticsearch | Semantic (RAG) | Lucene HNSW vector search with hybrid BM25 + kNN retrieval; self-host or Elastic Cloud | RAG / semantic | partial (open-core) | ↗ |
| OpenSearch | Semantic (RAG) | k-NN vector engine (HNSW via Lucene/Faiss/nmslib) with hybrid search; self-host, Apache 2.0 | RAG / semantic | yes | ↗ |
| Marqo | Semantic (RAG) | End-to-end vector search with built-in text+image embedding inference and HNSW; managed cloud or self-host engine | RAG / semantic | partial (open-core) | ↗ |
Durable structured state: the agent's tables, rows and facts.
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| PostgreSQL | Working · Semantic · Episodic | Open-source object-relational SQL DB; the default durable structured-state backend (plus pgvector for embeddings) | SQL query | yes | ↗ |
| Supabase | Working · Semantic · Episodic | Managed Postgres backend-as-a-service (pgvector, auth, realtime); hosted relational + vector memory store | SQL query | yes | ↗ |
| Neon | Working · Semantic | Serverless Postgres with branching, autoscaling and scale-to-zero; backend for apps and agents | SQL query | partial (open-core) | ↗ |
| PlanetScale | Working · Semantic | Managed relational platform (Vitess/MySQL + Postgres) built for scale and reliability | SQL query | partial (open-core) | ↗ |
| Amazon Aurora (RDS) | Working · Semantic · Episodic | Managed/serverless cloud relational DB (Postgres- and MySQL-compatible, with pgvector); enterprise agent-state backend | SQL query | no | ↗ |
| Cloudflare D1 | Working · Episodic | Managed serverless SQLite accessed from Workers/HTTP; edge-native relational store for agent state | SQL query | no | ↗ |
| Turso (libSQL) | Working · Semantic | SQLite/libSQL platform with embedded + edge-hosted DBs and native vector search; lightweight relational memory | SQL query | yes | ↗ |
Fast working memory and session state, often at the edge.
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| Redis | Working | In-memory key-value data-structure store (cache, DB, broker); fast working-memory and session state | Key lookup | yes | ↗ |
| Upstash Redis | Working · Episodic | Serverless Redis-compatible KV with REST API and global replication; per-request-priced working memory | Key lookup | no | ↗ |
| Momento | Working | Serverless low-latency cache + topics with no infra to manage; ephemeral working-memory layer | Key lookup | no | ↗ |
| Cloudflare Workers KV | Working | Global low-latency edge key-value store from Workers; eventually-consistent config/session state | Key lookup | no | ↗ |
| Cloudflare Durable Objects | Working · Episodic | Stateful serverless compute with co-located strongly-consistent storage; single-instance coordination/state at the edge | Key lookup | no | ↗ |
| Amazon DynamoDB | Working · Episodic | Serverless fully-managed NoSQL key-value/document DB at single-digit-ms latency; durable session/state store | Key lookup | no | ↗ |
Cheap long-term semantic storage on object/edge infrastructure.
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| Upstash Vector | Semantic (facts) | Serverless vector database over REST/SDKs for semantic search; embedding-backed long-term memory | Vector query | no | ↗ |
| Cloudflare Vectorize | Semantic (facts) | Edge-native vector DB on the Workers platform for storing/querying embeddings; semantic memory + RAG at the edge | Vector query | no | ↗ |
| Amazon S3 Vectors | Semantic (facts) | Purpose-built cost-optimized object storage for embeddings via vector buckets/indexes; cheap long-term semantic memory | Vector query | no | ↗ |
Human-readable knowledge bases the agent reads and writes.
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| Obsidian | Semantic · Procedural (notes) | Stores notes as local plain-text Markdown; agents read/write the vault via filesystem or Local REST API / MCP plugins | Markdown read/write (file / MCP) | no | ↗ |
| Notion | Semantic · Procedural (notes) | Stores pages, databases and comments; agents read/create/update via the official REST API or Notion MCP server | API / MCP | no | ↗ |
| Markdown / Filesystem (MCP) | Semantic · Procedural (notes) | Plain Markdown/text files on disk; agents read/write through the official MCP filesystem server (scoped dirs) | Markdown read/write (file / MCP) | yes | ↗ |
| Logseq | Semantic · Procedural (notes) | Local-first outliner storing pages/blocks as Markdown; agents read/write via files or its HTTP/plugin API | Markdown read/write (file / API) | yes | ↗ |
| Mem | Semantic · Episodic | AI note app that auto-captures and tags notes; agent reads/writes and resurfaces via natural-language retrieval | API / natural-language query | no | ↗ |
Entity/relationship memory: knowledge graphs and multi-hop recall.
| Provider | Layers served | Mechanism | Retrieval | OSS | src |
|---|---|---|---|---|---|
| Neo4j | Semantic · entity/relationship | Native property-graph store of nodes and relationships; agents read/write via Cypher (drivers, HTTP, MCP) | Graph (Cypher) / multi-hop | partial (open-core) | ↗ |
| FalkorDB | Semantic · entity/relationship | Ultra-fast multi-tenant property-graph DB tuned for GraphRAG/agent memory; agents read/write via Cypher | Graph (Cypher) / multi-hop | yes | ↗ |
| Memgraph | Semantic · entity/relationship | In-memory property-graph DB with Cypher and GraphRAG tooling (Neo4j-compatible); agents read/write via Cypher | Graph (Cypher) / multi-hop | partial (open-core) | ↗ |
| Amazon Neptune | Semantic · entity/relationship | Fully-managed graph DB storing property-graph and RDF; agents read/write via openCypher, Gremlin or SPARQL | Graph query / multi-hop | no | ↗ |
| ArangoDB | Semantic · entity/relationship | Multi-model DB unifying graph, document and vector; agents read/write graphs via the AQL query language | Graph (AQL) / multi-hop | partial (open-core) | ↗ |
Managed services, vector DBs, SQL, KV, object stores, notes, graphs
Fifty providers supply the storage under agent memory, against a much smaller set of frameworks. The supplier side keeps fragmenting while the framework side consolidates.
Show more
The question that raises is not whether agents need memory. It is why, with this much investment behind it, memory remains the part teams most often report getting wrong.
Where do AI agents store memory?
Usually in an ordinary database: Postgres for structured facts, a key-value store for session state, a vector database for search by meaning. Managed memory services sit on top of those and handle the extraction and retrieval for you. Graph databases come in when relationships between entities matter.
What is the difference between a memory service and a vector database?
A vector database does one thing: embed a query, return the nearest chunks. A memory service adds the surrounding work, extracting facts from conversations, removing duplicates, tracking which fact is current, and assembling the context before the model sees it. Same underlying storage, different amount of work done for you.
Should I self-host or use a managed memory service?
Self-host if you already run a database you are happy with and only need straightforward recall. Use a managed service when you want entity extraction, deduplication and time-aware retrieval handled for you, or when compliance and data residency drive the decision. Mem0 and Zep offer both open-source and hosted versions.
Do I need a graph database for agent memory?
Only if your questions cross entities, such as "what do we know about this customer across every system". For plain recall a vector store or SQL is simpler and cheaper to run. Neo4j, FalkorDB, Memgraph and ArangoDB are the usual choices when you do need one.
Should memory live at the edge or in a central database?
Session and working memory belong near the user, so a reply is not waiting on a round trip across the world. Long-term memory usually sits in one central store, where it costs less per gigabyte and is easier to keep consistent. Plenty of stacks do both.