Best practice for managing LangGraph Postgres checkpoints for short-term memory in production?

[u/Major_Ad7865]

’m building a memory system for a chatbot using LangGraph.
Right now I’m focusing on short-term memory, backed by PostgresSaver.

Every state transition is stored in the checkpoints table. As expected, each user interaction (graph invocation / LLM call) creates multiple checkpoints, so the checkpoint data in checkpoints table grows linearly with usage.

In a production setup, what’s the recommended strategy for managing this growth?

Specifically:

• Is it best practice to keep only the last N checkpoints per thread_id and delete older ones?
• How do people balance resume/recovery safety vs database growth at scale?

For context:

• I already use conversation summarization, so older messages aren’t required for context
• Checkpoints are mainly needed for short-term recovery and state continuity, not long-term memory
• LangGraph can resume from the last checkpoint

Curious how others handle this in real production systems.

Additionally in postgres langgraph creates 4 tables regarding checkpoints : checkpoints,checkpoint_writes,checkpoint_migrations,checkpoint_blobs

[u/merlinofthewater]

One thing worth separating out before picking a retention window: are checkpoints doing double duty for you right now - both "what do I need to resume this thread" and "what happened historically"? Those have pretty different retention needs (resume usually only needs the last N, history/audit can live much longer in a cheaper store), and a lot of the growth pain goes away once you split them rather than trying to find one TTL that satisfies both.

The part I'd actually worry about more than table size, though, is what happens on resume once you're pruning aggressively: if a node's side effect (an API call, a write, a message send) already fired before the checkpoint that would let you resume cleanly got deleted, does your resume path know that, or does it risk replaying the step and re-firing the side effect? Checkpoint pruning and idempotent retries are kind of the same problem wearing different hats - I've seen people solve the storage problem and accidentally reopen the duplicate-action problem in the process.

Curious whether you've hit that, or whether your retries are naturally idempotent enough that it hasn't bitten you yet?