Repository navigation
C1: pgvector adapter implementing BaseClient/BaseCollection + parity tests #12556
Description
Part of #12551 (Gap C).
Implement the pgvector backend named in knowledge/backends/base.py:8-11.
Scope
- New
knowledge/backends/pgvector_adapter.py:PgVectorClient(BaseClient)+PgVectorCollection(BaseCollection)mirroringchromadb_adapter.py(246 lines) and honouring the exact return-shape contract (base.py:19-27):get→flat-list dict,query→nested-list dict. - Reuse the Postgres connection seam from
services/memory/postgres_provider.py. - Parity tests: run the adapter against the same shared backend test-suite ChromaDB passes.
Acceptance
- Adapter passes the shared parity suite (add/upsert/update/get/query/delete/count/peek + collection lifecycle).
- Return shapes match ChromaDB 1.x exactly.
- No wiring into production selection yet (that's C2).
Activity
mrveiss commentedon Jul 26, 2026
Deferred (owner call, 2026-07-26): prioritised the higher-gain B-lane; pgvector rated low-value in the epic's Phase-2 audit (Chroma/Milvus already cover the vector-store need). Kept as a specced issue.
Architecture decision recorded for pickup: implement against the async ABCs (
AsyncBaseClient/AsyncBaseCollectioninknowledge/backends/async_base.py) using asyncpg — which is already a declared dependency — NOT the syncBaseClient(which would addpsycopg2, an undeclared dep, and violate the async-first rule). Add a skippable_pgvector_clientfixture toknowledge/backends/test_async_base.py's_BACKENDS(importorskip + skip when no Postgres+pgvector reachable) so the existing async parity suite validates it. Per-collection tables (dim inferred on first add) keep each collection'svector(N)index independent. C2 (#12557) then wires it viaAUTOBOT_VECTOR_BACKEND=pgvector(default chromadb) + aCREATE EXTENSION IF NOT EXISTS vectoridempotent migration.mrveiss commentedon Jul 26, 2026
Validation blocker (2026-07-26): completing C1 responsibly requires a Postgres+pgvector instance to run the async parity suite against — this session's environment has a Postgres server that rejects connections (no pg_hba entry / creds not available) and no Docker. Rather than ship ~250 lines of never-executed asyncpg SQL (low-value per the epic audit + unvalidatable here = speculative), C1 stays deferred with the async/asyncpg design recorded above. Pickup prerequisite: a PG-with-pgvector test env (CI service container or local instance) so the
test_async_base.pyparity fixture actually exercises the SQL path.