First met in aicp-c3-session-22 · Dev libraries & frameworks · Backend, hosting & code
Open-source vector database with an embedded mode — the searchable memory a RAG system stores its chunks in.
You want vector search inside the process (single-tenant, on-prem, laptop-sized) instead of a hosted vector-database service.
Embedded mode runs in-process — Session 22's build used one collection per conversation with no service to operate
Part of a ~107MB install alongside Haystack — vector search without infrastructure
Scales up to a real clustered service later without changing the mental model
Stores embeddings and runs similarity search over them
Isolates corpora cleanly (collection-per-conversation in the Talent Lens build)
Serves both the demo (OpenAI embeddings) and production (local) paths unchanged
Doesn't create embeddings — an embedding model does that upstream
Doesn't replace retrieval logic — chunking, overlap, and evidence gates live in the orchestrator
Embedded mode isn't multi-tenant infrastructure — that's what the server product is for
The vector store slot in a lightweight RAG stack; the 'database is just a library' answer for on-prem builds.
Dev libraries & frameworks · Backend, hosting & code
Would be the storage layer if the KB gains semantic search; nothing built on it yet.
Embedded mode fits Paul's single-tenant KB exactly — no new service to run.
current
haystack: Chosen together in Session 22 after the measured comparison
supabase: pgvector on Supabase is the hosted-Postgres answer to the same storage question
| Session | Coverage | Moment | What happened |
|---|---|---|---|
| Session 22: Automate Admin Tasks — Advanced RAG (Enterprise 'Internal Perplexity' Built Live) | demonstrated | Embedded mode — one collection per conversation, no separate service |