What this stack is for
You have a pile of documents, and people keep asking questions the pile could answer. This stack is "chat with our docs" built honestly: Postgres with pgvector instead of a separate vector database you would have to run and pay for, hybrid retrieval instead of pure similarity vibes, and a citation on every answer so a wrong one can be traced instead of trusted. If the answer cannot point at its source, it is not an answer. That rule is load-bearing here.
Components
- Postgres — the relational database underneath everything, including vectors
- pgvector — the Postgres extension that stores and searches embeddings
- Supabase — hosts the Postgres + pgvector database, plus auth if needed
- Vercel — hosting, deploys from git, preview URLs per branch
- Vite + React — the frontend build and UI layer
How the pieces fit
- Documents are ingested and split into chunks sized for good retrieval
- Each chunk is embedded and stored as a vector in pgvector alongside its source text
- A query is embedded the same way, then matched against stored vectors with hybrid search (vector + keyword)
- The top matching chunks are passed to the model as context, with citations back to source
- The model answers using only the retrieved chunks, citing which document each claim came from
Setup outline
- Create the Supabase project and enable the pgvector extension (full walkthrough coming)
- Write the ingestion + chunking pipeline for the source documents (full walkthrough coming)
- Embed each chunk and store it in pgvector (full walkthrough coming)
- Build the hybrid retrieval query — vector similarity + keyword (full walkthrough coming)
- Wire retrieval into the prompt with citations back to source chunks (full walkthrough coming)
- Deploy the app to Vercel (full walkthrough coming)
What to hand your agent
Retrieval quality is decided by unglamorous details, so give the agent the details:
- The full stack description above, plus the PRD and a sample of the source documents
- The chunking strategy (size, overlap) if one is already decided
- The instruction to always cite the source chunk, never answer from outside the retrieved context
Adaptation notes
- A dedicated vector database (Pinecone, Weaviate) can replace pgvector if scale outgrows one Postgres instance
- Reranking after retrieval improves answer quality when the document set is large or noisy
- Chunking strategy is the single highest-leverage tuning knob in this stack; get it wrong and everything downstream suffers