smooai-smooth-operator-adapter-postgres 1.2.0

Postgres + pgvector StorageAdapter for smooth-operator — the dogfood backend (Postgres OLTP, PostgresCheckpointStore, pgvector hybrid retrieval).
Documentation

Postgres + pgvector [StorageAdapter] — the dogfood backend.

This is the production Postgres implementation of the one storage seam (see docs/STORAGE.md). It mirrors the smooai monorepo's schema so dogfooding is a swap, not a rewrite:

  • OLTP (conversations / participants / messages / sessions): async CRUD over a [deadpool_postgres] pool, semantics matching the in-memory baseline (conversation idempotency, external-id participant resolve, cursor message paging, session status/counts).
  • Checkpoints: smooth-operator's PostgresCheckpointStore (a synchronous r2d2-pooled store) constructed against the same database — so the engine's with_checkpoint_store plugs straight in and agent state lives next to the conversations it belongs to.
  • Knowledge: a pgvector-backed [PgKnowledgeBase] (dense HNSW cosine ∪ sparse tsvector BM25 → Reciprocal Rank Fusion). Text→vector goes through the [Embedder] seam — [DeterministicEmbedder] by default (reproducible, no network), [GatewayEmbedder] when a live gateway is configured.
  • Memory: a pgvector-backed [PgMemory] (parity gap Phase 3 / SMOODEV-1470) — persistent, semantic, cross-thread agent memory namespaced by (organization_id, user_id) like the TS ['memories', orgId, userId] store. Implements the core Memory trait; recall is pgvector cosine top-K under an HNSW index, scoped to the namespace. Shares the adapter's [Embedder].

Sharing one database between the async pool and the sync checkpoint store

The OLTP/knowledge slices need async (tokio-postgres + deadpool); the checkpoint slice is a sync trait backed by an r2d2 pool inside smooth-operator. Both are pointed at the same conn_str: we build the async deadpool from it for our own queries, and hand the same string to PostgresCheckpointStore::connect, which stands up its own small r2d2 pool and checkpoints table in that database. Two pools, two driver stacks, one Postgres — the tables coexist (ours from [schema], theirs from their own CREATE TABLE IF NOT EXISTS).