Why my first RAG layer starts in Postgres, not in a standalone vector database

A developer argues that the first retrieval layer for operational AI workflows should start in Postgres with pgvector, not in a standalone vector database, prioritizing control, review, and schema clarity over architectural novelty. The approach keeps retrieval, evaluation, and auditability visible by storing metadata alongside chunks and using failure criteria like golden-question sets. A public case study is available on GitHub.

When people say they are "adding RAG" to a workflow, the conversation often jumps too quickly to infrastructure choices. Should this use a vector database? Should there be a reranker? Should everything go into a knowledge graph? Those are valid questions, but they are usually not the first question. The first question is narrower: What approved knowledge should the workflow be allowed to retrieve before an AI decision happens? That is why my first retrieval layer for operational AI workflows starts in Postgres, not in a standalone vector database. In operations-heavy systems, the model usually should not answer from raw memory or from a giant prompt dump. The useful context already exists somewhere else: The hard part is not generating fluent text. The hard part is retrieving the right approved context, showing which source influenced the decision and refusing when no safe source exists. For this kind of workflow, most of the surrounding data is already relational: So the first technical choice is not "where do vectors live in the abstract?" It is: Postgres plus pgvector is a good first answer to that set of questions. It lets me keep: in one place. The first version does not need to be broad. It needs to be inspectable. My narrow retrieval scope looks like this: Each retrieved chunk should carry more than text. It should also carry metadata such as: That metadata matters because a workflow may be allowed to use one chunk as internal reasoning support, but not as customer-facing language. I do not think a retrieval layer is real until it has failure criteria. So the public prototype includes a small golden-question set: That matters more than announcing that the system has embeddings. Without retrieval checks, a RAG layer can look sophisticated while still pulling the wrong context. The retrieval step and the AI decision step should be traceable together. I want the same review surface to show: That is the bridge between "the system answered" and "the system answered for a defensible reason." I am not against standalone vector databases. I would add one later if the system needed: But before that point, I prefer a smaller stack that makes retrieval, evaluation and auditability visible. For AI workflows in revenue or operations contexts, the first retrieval layer should optimize for control, review and schema clarity. Not for maximum architectural novelty. That is why my first RAG layer starts in Postgres: The public case study is here: https://github.com/rkrisa/portfolio-ai-ops/tree/main/cases/operational-knowledge-retrieval-layer https://github.com/rkrisa/portfolio-ai-ops/tree/main/cases/operational-knowledge-retrieval-layer