Expand description
Async PostgreSQL graph backend over sqlx::PgPool (feature graph-pg-sqlx) —
for consumers (e.g. klr) that own an async pool and need transaction sharing.
Async PostgreSQL graph backend over sqlx::PgPool (feature graph-pg-sqlx).
SqlxPgGraph mirrors the SQL/DDL/semantics of the synchronous PgGraph
(graph-pg), but drives every operation asynchronously over a shared
sqlx::PgPool instead of one mutex-guarded postgres::Client. The SQL is
ported verbatim from pg.rs — only the driver changes (sqlx prepared-statement
cache + connection pool instead of blocking postgres::Client).
§Why a second PostgreSQL backend?
Consumers that already own a sqlx::PgPool (notably korean-law-rag’s klr
citation graph) cannot share a pool or transaction with PgGraph, which is
built on a synchronous postgres::Client. SqlxPgGraph lets such consumers
adopt the llm-kernel graph on their own pool and — critically — expose the
transaction so a multi-table prune (chunks + vectors + edges in one tx)
stays atomic. See SqlxPgGraph::pool and the *_in_tx methods.
This backend is intentionally non-breaking: it is a new module that does
not touch GraphBackend, PgGraph, or any other file. The SQL/schema is
identical to PgGraph, so the two backends can share one database (use a
table_prefix to namespace tables when both run side by side).
§Scope
Inherent async methods cover klr’s needs — batch edge writes, directed /
relation-filtered lookups, weighted neighbor aggregation, search, and
traversal — plus basic node/edge CRUD. query_nodes and smart_recall
(which would require porting the CSR PageRank pass) are out of scope: a
citation graph does not need memory-recall ranking. They are marked with
TODO(post-1.0) comments.
Structs§
- Sqlx
PgGraph - Async PostgreSQL graph backend over a shared
sqlx::PgPool.