Hey! Not a support question, but I built a checkpointer backend and want your take
on where it should live.
It saves checkpoints to Tigris (S3-compatible object storage).
Tigris can fork a whole bucket instantly, zero copy. So you can branch an
agent’s entire checkpoint history in one call.
Withfork() you can have an isolated saver that already sees every past checkpoint, and new writes stay separate from the original.
Basically free time-travel / what-if branches, which Postgres and SQLite can’t really do.
So: would you want it in-tree as libs/checkpoint-tigris, or rather I publish
it and you link it from the docs? Either’s totally fine, just need to know how to go about it. Thanks!
Hello @davidmyriel welcome to the LangChain community.
Publish it separately, then get it listed in the docs.
Most provider-specific checkpointers live outside the main langgraph repo and are linked from the checkpointer integrations page, same pattern as Redis, Aerospike, CockroachDB, etc.
For Tigris specifically:
- Publish something like
langgraph-checkpoint-tigris from your own repo, implementing BaseCheckpointSaver.
- Run the conformance suite (
langgraph-checkpoint-conformance) so it works with Agent Server, especially if you want LangSmith/self-hosted deployments via langgraph.json.
- If you expose bucket fork() as checkpoint branching, implementing acopy_thread would be a strong fit, the custom checkpointer docs list it as an optional extended capability, with a slow fallback that re-inserts checkpoints one by one if it’s missing.
- Open a PR to langchain-ai/docs to add a row on the integrations index.