How do you keep LangGraph checkpoint storage from becoming a production liability?

## Why this bites late Checkpointing looks free in development. A demo has ten threads, five steps each, and a state of a few kilobytes. In production the same code writes on every super-step of every concurrent run, forever, and nothing in the framework prunes it. Teams typically discover this as a database that grew a hundred times in a quarter, or as p99 latency creeping up on a chat endpoint that got no slower in the model. ## The volume model Approximate the write volume as **threads x super-steps per thread x state size per checkpoint**, plus task-level write records within steps, plus a branch per time-travel rewind. Three of those four terms are set by design decisions: - **State size** is the dominant term and the one people ignore. Because a checkpoint stores the full state rather than a diff, a 2 MB blob parked in state is re-serialised and re-written at every step. Twenty steps means 40 MB for one run. The fix is architectural: state carries an object key, a document id, or a URI, and the node fetches the payload when it needs it. Retrieved chunks, uploaded files, images and large tool outputs should almost never live in state. - **Steps per thread** is graph granularity. Fine-grained nodes buy precise crash recovery and cost more checkpoints; coarse nodes are cheaper to persist and redo more work on resume. That is a genuine tradeoff to make deliberately, not accidentally. - **Thread lifetime** is product design. A conversation that never ends is a checkpoint chain that never stops growing, and each of its steps re-writes an ever-longer message history — quadratic in the conversation length. Bounding a thread (session windows, summarisation into a smaller state channel, or moving durable facts to a cross-thread store) is the standard mitigation. ## Durability as a per-workload knob In LangGraph 1.x, `invoke` and `stream` accept `durability` with values `"exit"`, `"async"` (default) and `"sync"`. This is a capacity lever, not only a safety one: - High-volume, short, cheap graphs — classification, extraction, routing — often justify `"exit"`: one write per run instead of one per step, at the cost of resumability you would never have used. - Long, expensive, externally observable runs justify `"sync"`: the added per-step latency is trivial next to redoing an LLM call or a human approval. - Most interactive work sits on the default `"async"`. Because the argument is per-invocation, one service can apply all three against the same checkpointer, and choosing per route is a cheap win. ## Retention and deletion Nothing expires on its own. You need a policy and something that enforces it: - Decide how long a finished thread stays queryable. Support and audit usually want some window; forever is not a policy. - Have a way to delete a thread's checkpoints outright — recent checkpointer versions expose a thread deletion operation on the interface, and where a version does not, deleting by thread key in the backing store is the fallback. This is not optional if you are subject to data-deletion requests, because the checkpoint database holds the conversation. - Remember that time travel forks rather than overwrites, so threads that are repeatedly rewound carry several branches. Rewind-heavy workflows need tighter retention than their thread count suggests. ## Privacy and security Checkpoints are the highest-fidelity record of what a user said and what the agent did — usually more complete than your logs. Consequences to state plainly: - The checkpoint database is in scope for the same classification, encryption-at-rest and access-control rules as your primary user data, and often stricter, since it captures raw prompts. - Access to `get_state_history` is effectively access to conversation transcripts; whatever admin surface exposes it needs authorisation, not just an internal URL. - Serialisation is the boundary at which secrets leak: a credential or token pulled into state to pass between nodes is written to disk at every subsequent step. Pass identifiers and resolve secrets inside the node instead. ## Database placement and connections Agent checkpoints have a write-heavy, high-churn profile that is unlike most OLTP tables, so putting them in their own database or at least their own schema keeps vacuum, bloat and backup pressure away from your product tables — and lets you set retention independently. Connection sizing is the other common miss: with an async saver, every super-step of every concurrent run issues a write, so the pool must be sized against **concurrent in-flight runs multiplied by their step rate**, not against HTTP requests per second. Under-provisioning shows up as runs stalling on connection acquisition, which looks like model latency in a naive trace. ## What a strong answer sounds like Not "add an index". It is: bound the state, bound the thread, choose durability per workload, isolate and size the database, and own retention and deletion of what is, in effect, a transcript store. The framework gives you durability; the liability is yours to manage.