The cheapest RAG is the one you already pay for
Retrieval augmented generation does not always need a managed vector database. If your data already lives in Postgres, the pgvector extension keeps embeddings right beside it, joinable with business data, governed by the same access rules, and billed on the same instance you are already running.
When pgvector is the right call
- Your corpus fits comfortably alongside your existing Postgres workload.
- You want to join semantic results with relational data, filtering by tenant, status, or date, in a single query.
- You would rather not add another vendor, another bill, and another failure mode.
The schema and the search
An embedding is just a column. You store the vector next to the row it describes and add an index so nearest neighbour search stays fast as the table grows.
create extension if not exists vector;
alter table documents add column embedding vector(1536);
create index on documents
using hnsw (embedding vector_cosine_ops);
The query that makes this powerful is the one a separate vector database cannot write, because it joins the semantic match to the relational filter in one statement:
select id, title, url
from documents
where tenant_id = $1 and doc_type = 'guide'
order by embedding <=> $2
limit 8;
The <=> operator is cosine distance. The where clause is ordinary SQL. One round trip returns the closest matches that also satisfy your business rules, with no application side merging of two systems' answers.
When to reach for a managed vector database instead
- Very large corpora with demanding latency targets at high query volume.
- You want integrated inference and managed scaling out of the box.
The point
This is a choice made per workload, the same vendor neutral instinct that runs through the whole stack. For most products the corpus is modest and the value is in joining it to the data you already hold. In that common case, the database you are already paying for is also your retrieval layer, and that is one fewer thing to operate.