Expand description
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_postgrespool, 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’swith_checkpoint_storeplugs straight in and agent state lives next to the conversations it belongs to. - Knowledge: a pgvector-backed
PgKnowledgeBase(dense HNSW cosine ∪ sparsetsvectorBM25 → Reciprocal Rank Fusion). Text→vector goes through theEmbedderseam —DeterministicEmbedderby default (reproducible, no network),GatewayEmbedderwhen 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 coreMemorytrait; recall is pgvector cosine top-K under an HNSW index, scoped to the namespace. Shares the adapter’sEmbedder.
§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).
Structs§
- Deterministic
Embedder - Deterministic, network-free pseudo-embedder.
- Gateway
Embedder - OpenAI-compatible
/v1/embeddingsembedder (the SmooAI LiteLLM gateway). - Gateway
Reranker - Cross-encoder reranker over the SmooAI gateway’s
/v1/rerankendpoint (feature gap G8). - Http
Rerank Backend - The real backend: a Cohere/Voyage-style
/v1/rerankcall over the gateway. - PgConnector
Config Store - Postgres-backed
ConnectorConfigStoreoverconnector_configs. - PgIndexing
Store - Postgres-backed
IndexingStoreoverindexing_runs. - PgKnowledge
Base - pgvector knowledge base. Cheap to clone (all fields are
Arc/pool handles). - PgMemory
- pgvector-backed agent memory, bound to one
(organization_id, user_id)namespace. Cheap to clone (all fields areArc/pool handles + small strings). - PgSettings
Store - Postgres-backed
SettingsStoreoveragent_settings. - Postgres
Adapter - Postgres + pgvector storage adapter.
- Rerank
Score - One scored candidate returned by a
RerankBackend: the candidate’s index in the requestdocumentsarray, and its relevance score against the query.
Enums§
- Input
Type - Whether an embedding is for a document being stored or a search query.
Constants§
- DEFAULT_
EMBEDDING_ DIM - Default embedding dimension (Voyage
voyage-3-largeshape; mirrors smooai’sknowledge_vectors embedding vector(1024)). - DEFAULT_
RERANK_ MODEL - Default rerank model requested over the gateway (Cohere-compatible). Distinct from the embedding model and the chat model.
- OPENAI_
SMALL_ EMBEDDING_ DIM - Dimension returned by OpenAI
text-embedding-3-small.
Traits§
- Embedder
- Turn text into dense vectors. Implementations must return one vector per
input string, each of length
Embedder::dim. - Rerank
Backend - A pluggable rerank backend.