# Feature Request: Driver abstraction for checkpoint-postgres: to build support for asyncpg and other adapters .Interested to contribute to langgraph (python) **URL:** \ **Category:** LangGraph\ **Tags:** product-feedback, python-help, feature-request\ **Created:** [April 25, 2026, 9:23pm UTC](https://forum.langchain.com/t/feature-request-driver-abstraction-for-checkpoint-postgres-to-build-support-for-asyncpg-and-other-adapters-interested-to-contribute-to-langgraph-python/3592 "2026-04-25T21:23:55Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![shantam29](https://avatars.discourse-cdn.com/v4/letter/s/b2d939/32.png) [@shantam29](https://forum.langchain.com/u/shantam29)\ **Post date:** [April 25, 2026, 9:23pm UTC](https://forum.langchain.com/t/feature-request-driver-abstraction-for-checkpoint-postgres-to-build-support-for-asyncpg-and-other-adapters-interested-to-contribute-to-langgraph-python/3592/1 "2026-04-25T21:23:55Z")
Hey all , I’ve been working with langgraph postgres checkpointer on a client project and ran into an issue. Current checkpoint-postgres is tightly coupled to psycopg3, which is actually a great choice , natively asyc , unified sync/async api. However we kind of hit a real world blocker recently. Client’s legal team flagged psycopg3’s LGPL license during procurement review. So we had to shift to asyncpg (Apache 2.0) instead. So I was thinking that it’d be nice to introduce a thin driver adapter interface, like a PostgresDriverAdapter ABC that handles execute / executamy / connection lifecycle. psycopg3 behaviour stays as the default implementation, but it opens doors for commnity maintained adapters for asyncpg , SQLAlchemy or whatever else people need The sql constants , serde and migration logic in BasePostgreSaver is already well separated, the driver boundary really is the only thing that is missing. Let me know if you’re open to it I know it might require documentation updates as well. Would love to contribute to both