tl  tr
  Home | Tutorials | Articles | Videos | Products | Tools | Search
Interviews | Open Source | Tag Cloud | Follow Us | Bookmark | Contact   
 Agentic AI > LangGraph > LangGraph Persistence with Checkpointers

LangGraph Persistence with Checkpointers

Author: Venkata Sudhakar

By default a LangGraph agent has no memory between calls - each invocation starts fresh with an empty state. Checkpointers add persistence by saving the full state of the graph after every node execution. This enables two critical capabilities: multi-turn conversations where the agent remembers what was said in previous turns, and resumable execution where a long-running agent can be paused and resumed later without losing progress. Both use the same mechanism - a thread_id identifies the conversation, and the checkpointer stores and retrieves the state for that thread.

LangGraph provides two built-in checkpointers. MemorySaver stores state in a Python dictionary in memory - perfect for development and testing but lost when the process restarts. SqliteSaver (from langgraph-checkpoint-sqlite) stores state in a SQLite file - persists across restarts, ideal for local applications. For production deployments, use PostgresSaver (langgraph-checkpoint-postgres) to store state in PostgreSQL shared across multiple server instances. The checkpointer is passed at compile time and is transparent to the rest of the graph code.

The below example shows a simple chat agent with MemorySaver that remembers the full conversation history across multiple calls using a thread_id.


It gives the following output,

Turn 1: Nice to meet you, Venkata! Data migration is a fascinating field.
How can I help you today?

Turn 2: Your name is Venkata, and you work on data migration.

# The agent remembered the information from Turn 1
# without it being passed explicitly in Turn 2
# The full message history is stored in the checkpointer keyed by thread_id

It gives the following output after process restart,

You mentioned you have 50 tables to migrate.

Messages in state: 4
# 4 messages: 2 human + 2 AI, persisted across restarts in SQLite

Each thread_id is a completely independent conversation with its own state history. Use a unique thread_id per user session, per task, or per conversation. For production web applications, generate a UUID as the thread_id when a new chat session starts and store it in the user session. The checkpointer also enables the human-in-the-loop pattern covered in the LangGraph Human-in-the-Loop tutorial - interrupt_before works by saving the state at the interruption point so it can be resumed after human review.


 
  


  
bl  br