Integrations: swapping in real backends

An integration is the real backend that replaces a local stand-in: a persistent checkpointer, a real chat model, or a vector store, each a drop-in for the in-memory piece you already used.

Last updated: 27 Sep, 2026 · LangGraph 1.2

The course ran on in-memory pieces so it needed no setup. To ship, you swap each one for a real backend. The graph code does not change; only the piece you pass in does.

The pieces you used, and their real versions

Why the swap is drop-in

Every real checkpointer subclasses the same BaseCheckpointSaver that InMemorySaver does, so the graph accepts any of them in the same checkpointer= slot.

from langgraph.checkpoint.base import BaseCheckpointSaver
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.checkpoint.sqlite import SqliteSaver

for saver in (InMemorySaver, SqliteSaver):
    print(saver.__name__, "is a checkpointer:", issubclass(saver, BaseCheckpointSaver))

Using a persistent checkpointer

Install the backend's package, open the saver, and compile with it. The checkpointer= call is the one from the checkpointer lesson, now pointing at a file.

# pip install langgraph-checkpoint-sqlite
from langgraph.checkpoint.sqlite import SqliteSaver

# same compile call, a real file instead of memory
with SqliteSaver.from_conn_string("checkpoints.db") as saver:
    graph = builder.compile(checkpointer=saver)

InMemorySaver vs SqliteSaver vs PostgresSaver

When to switch a piece

• Anything a user comes back to needs a persistent checkpointer, not InMemorySaver.
• A real assistant needs a hosted chat model in place of the stand-in.
• RAG over real documents needs a vector store, not the keyword search.

Related

• Previous: RAG: answering from what you found
• Next: Deploy: langgraph dev and langgraph.json
• Reference: Checkpointer integrations