LangGraph/Persistence
Intermediate18 min

Long-term Memory with Store

LangGraph Store is a cross-thread key-value database that persists facts across every conversation a user has. This article covers when to use it, how the full API works including TTL and semantic search, the hard problem of memory extraction, a production-grade load-reason-save pattern, and the five failure modes that break agents in production.

Quick Reference

  • Store is cross-thread; checkpointers are per-thread — never mix their roles
  • namespace = (user_id, category) — tuples, not strings; no registration required
  • store.get() is O(1) exact lookup; store.search() embeds the query and costs an API call
  • store.put(ns, key, val, ttl=N) — TTL is in minutes; omit it and the memory lives forever
  • Memory extraction — deciding what to save — is harder than the put() call itself
  • InMemoryStore for dev, AsyncSqliteStore for lightweight prod, AsyncPostgresStore for scale
  • LangMem's create_manage_memory_tool lets the agent decide what to remember
  • Stale memories poison context as reliably as missing ones — TTL and deterministic keys are not optional

Should You Use Store?

Before you write a single store.put() call, answer this question: does this data need to survive when a new conversation starts? If yes, use Store. If no, use checkpointer state or in-memory reducers — Store adds a round-trip to an external database for every read and write, and that cost is only worth it when the data genuinely outlives the conversation.

Checkpointerthread-scoped auto-saveThread Auser-123 · session-1ckptckptckptstep 1 → 2 → 3Thread Buser-123 · session-2ckptckptstep 1 → 2no cross-thread accessPostgresSavercheckpoints tableStore (BaseStore)cross-thread, explicit put/searchnamespace: (user-123, "memories")survives new threads, sessions, restartsThread A stores prefThread B reads pref✓ shared across threadsPostgresStorestore.put / store.searchUse for: resume, HITL, time travelUse for: user prefs, long-term facts,cross-session memory

Checkpointer = thread-scoped auto-save · Store = cross-thread shared memory

Use Store when...Don't use Store when...
User preferences persist across weeks or monthsTracking conversation context within one thread
Agent learns facts about a user over timePassing data between nodes in one graph run
Multiple threads need shared knowledgeData is only relevant for the current session
Building a personalized experience per userYou need rollback or time-travel (use checkpointer)
Episodic history across session boundariesThe value is large binary data (use object storage)
The most common Store mistake

Using Store for within-conversation state. If you are storing the current message list, intermediate tool results, or temporary reasoning steps in Store, you are adding database latency to every node for no benefit. Checkpointer + state reducers handle within-conversation state. Store handles across-conversation facts.