A LangGraph Postgres checkpoint read can scan old blob versions

A LangGraph JavaScript issue reports PostgresSaver.getTuple() and list() reading more historical blob versions than a single checkpoint needs. The returned state remains correct, so an agent may look healthy while checkpoint reads become slower as a thread accumulates versions. Buying faster model capacity will not shorten a database scan.

Diagnose the boundary

Measure checkpoint read latency by thread age and inspect the actual SQL with EXPLAIN (ANALYZE, BUFFERS) on representative data. The report reproduced a plan that scans historical blobs for a thread instead of using the primary key's thread, namespace, channel and version fields. PostgreSQL's EXPLAIN guide shows how to distinguish the chosen plan from what an index could support. Compare recent and old threads, and separate model time from saver time in traces.

Decide the next safe change

The issue proposes a lateral lookup for each referenced channel version, but a proposed query is not a deployed fix. Test a release candidate on a copy of representative history and compare both plan and result sets for current, historical and pending-write reads. Avoid purging checkpoints to improve one graph without checking recovery and audit requirements. If latency is material now, limit unnecessary state reads and give the database team the precise slow query and plan.

Evidence boundary

The issue reports a PostgreSQL 16 query-plan reproduction on @langchain/langgraph-checkpoint-postgres 1.1.2. Values remain correct; the concern is read cost as historical versions accumulate. The proposed lateral lookup is not a verified release.

Adovo’s view

Agent latency often hides in state retrieval. A correct answer that gets slower with every turn is an operating problem even before it becomes an outage. Measure the storage path as the thread grows, then change the query with proof that history still resolves correctly.