persistence & checkpointing

8 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Checkpointer API protocol hierarchy and capability detection

The Checkpointer API uses a two-level protocol hierarchy for improved extensibility. Capability detection supports extended methods directly, allowing custom checkpointers to implement async methods like `acopy_thread`, `aprune`, and `adelete_for_runs`. The API includes generic fallbacks in the BYOC (Bring Your Own Checkpointer) adapter to simplify implementation for custom checkpointers across different storage backends.

Agent Server checkpoint optimization via inlining small values

As of v0.2.91, writes to the checkpoint_blobs table were reduced by inlining small values such as null, numeric, and string types, eliminating the need to store extra values for channels that have not been updated.

Agent Server checkpoint foreign key simplification

In v0.2.89, checkpoint writing was decoupled from thread/run state by removing foreign keys. In v0.2.88, the foreign key constraint for thread in the run table was removed to simplify the database schema.

Minimize redundant checkpointing via durability setting

Minimize redundant checkpointing by setting durability to the minimum value necessary to ensure data is durable. The default durability mode is 'async', meaning checkpoints are written after each step asynchronously. If an assistant needs to persist only the final state of the run, durability can be set to 'exit', storing only the final state of the run. This can be set when creating the run via the durability parameter.

Set TTLs to automatically delete old thread data

Set a TTL on threads to automatically clean up old data. Runs and checkpoints are automatically deleted when the associated thread is deleted.

Checkpoint and persistence configuration in deployed graphs

When deploying a graph, do not configure checkpointers and memory stores in your graph code because the server automatically injects the checkpointer and memory store configured for that deployment at runtime, and the server needs to manage them for other operations.

Three types of persisted data in Agent Server

Agent Server persists three types of data, all backed by PostgreSQL by default: (1) Core resource data (assistants, threads, runs, and cron jobs) - always stored in PostgreSQL. (2) Checkpoints (short-term memory) - snapshots of graph execution state written at each step that make runs durable so they can resume from the last checkpoint if a worker is interrupted. Durability mode controls checkpoint frequency with 'async' (default) writing after each step and 'exit' storing only the final state. LangSmith stores this in PostgreSQL by default but you can switch to MongoDB or a custom implementation. (3) Store (long-term memory) - memory that persists across threads, enabling agents to retain information between separate conversations, stored in PostgreSQL by default but can be replaced with a custom implementation.

Three durability modes for checkpoints in LangGraph

LangGraph checkpoint durability modes control checkpoint frequency: 'async' (default) writes checkpoints after each step, and 'exit' stores only the final state. A third mode exists in the system for full control of checkpoint behavior.

Give your agent this brain