Hi,
We have an OData API (REST) to manage checkpoints and checkpoint writes and don’t unfortunately have a way to bypass the API layer and directly perform checkpoint operations on the DB layer itself. I see that existing checkpoint such as postgres and others are directly at DB-layer. Any suggestions for checkpoints via API layer.
Best, Santosh
yes, this can work. LangGraph does not require the checkpointer to talk directly to a DB. Postgres and SQLite savers are just implementations of the BaseCheckpointSaver contract. In your case I’d build a custom saver that maps put/aput, put_writes/aput_writes, get_tuple/aget_tuple, list/alist, and delete_thread/adelete_thread to your OData API.
The main thing is to preserve the same semantics: checkpoints should be keyed by thread_id, checkpoint_ns, and checkpoint_id, and writes should be linked to the same checkpoint plus task_id, task_path, and write index. Make sure get_tuple can fetch both the latest checkpoint and a specific checkpoint_id, since replay, time travel, pending writes, and delta-channel reconstruction depend on that.
I’d also avoid hand-serializing checkpoint data as plain JSON. Use the LangGraph saver serde methods for checkpoints, metadata, and write values, then store the typed blob through your API, for example as binary or base64. Finally, run langgraph-checkpoint-conformance against the custom saver - it will catch most compatability issues early. So overall, an API-layer checkpointer is fine, but the OData service needs to expose the same read/write/indexing behavior LangGraph expects from the DB-backed savers.