LangGraph Agents

Course Content

LangGraph Agents

7 sections · 49 lessons

What checkpointers exist (in-memory vs sqlite vs postgres), and how do you choose?


What changed when the claims service scaled to four replicasSqliteSaver on one pod• Survives restarts on a volume• One writer at a time• Approval lands on another replica• About 1% of resumes failAsyncPostgresSaver• Survives restarts and deploys• Many processes, one database• Any replica can resume any claim• Non-blocking in an async server
The right saver is decided by two questions: must state survive a restart, and can more than one process touch a thread.

What you need to know

InMemorySaverSqliteSaverPostgresSaver
Packagelanggraphlanggraph-checkpoint-sqlitelanggraph-checkpoint-postgres
Survives restartNoYes (file)Yes
Many processesNoPoor (one writer)Yes
Use forTests, demosLocal tools, prototypesProduction
Async versionSame classAsyncSqliteSaverAsyncPostgresSaver

MemorySaver is an older alias of InMemorySaver; both still work.

Python
from langgraph.checkpoint.postgres import PostgresSaverDB_URI = "postgresql://app:secret@db:5432/agents?sslmode=require"with PostgresSaver.from_conn_string(DB_URI) as checkpointer:    checkpointer.setup()                 # create tables; run once, e.g. in a migration    graph = builder.compile(checkpointer=checkpointer)    graph.invoke(inputs, {"configurable": {"thread_id": "claim-88213"}})

For a web server, create a connection pool once at startup and use AsyncPostgresSaver with ainvoke or astream, so checkpoint writes do not block the event loop. Community savers exist for Redis, MongoDB and others.

The managed option

LangGraph Platform was renamed in October 2025. The runtime is now Agent Server, and managed hosting is LangSmith Deployment (cloud, hybrid or self-hosted). It gives you Postgres-backed checkpoints, a task queue, a threads and runs API, cron jobs and LangSmith Studio (formerly LangGraph Studio) for debugging. When you deploy there, you do not pass a checkpointer; the server provides one. Locally, langgraph dev runs an in-memory Agent Server for development.

A real-life example

A health insurer's claims workflow started as a demo with InMemorySaver. In the pilot, running as one container with SqliteSaver, a deploy restarted the pod and the claims kept going — the SQLite file was on a persistent volume. When the service scaled to four replicas behind a load balancer, an adjuster's approval sometimes landed on a replica that could not see or lock the file, and resumes failed about 1% of the time. Moving to AsyncPostgresSaver on the company's managed Postgres fixed it; any replica can now resume any claim.

Follow-up questions to expect

  • "Why not Redis for everything?" — Redis savers exist and are fast, but you must configure persistence and memory limits; Postgres is the default because it is durable and already run by most teams.
  • "Where does long-term memory go?" — A Store, not the checkpointer: InMemoryStore or PostgresStore, passed as store= to compile.
  • "Do subgraphs need their own checkpointer?" — No. Compile only the parent with one; it is passed down.