Your agent needs a vector database.

Your agent needs a vector database. You might already be running one.

Every agentic AI architecture diagram has a box labeled “vector store,” usually drawn as a separate system from everything else. For most teams, that box is unnecessary — and the reason why has nothing to do with cost savings.

Hi there —

Welcome to Issue #7 of Vacuum & Analyze. Different topic this time — less “why is my database slow,” more “you’re about to add a new database to your stack, and you might not need to.”

If you’re building anything agentic — a retrieval loop, a memory system, a RAG pipeline — you’ve probably already sketched an architecture with Postgres for your relational data and Pinecone, Weaviate, or Qdrant for embeddings. This issue is about why that second system is often a mistake, not a best practice.

Misconception #1: “Vector search needs a specialized database”

An agent’s memory is three operations: embed some content, store the vector, retrieve the nearest neighbors to a query vector. That’s a similarity search problem — it doesn’t require a new category of infrastructure, it requires a data type and an index. pgvector adds exactly that to Postgres: a vector column type, distance operators, and index types built for approximate nearest-neighbor search at scale.

The instinct to reach for a dedicated vector database usually comes from a mental model where Postgres means “rows and joins” and similarity search feels like it belongs somewhere else. It doesn’t.

Misconception #2: “Filtering is a detail I’ll handle after retrieval”

This is the one that actually costs teams real latency and complexity. Almost no real agentic retrieval wants “most similar vector, full stop” — it wants “most similar vector, given these business constraints”: this customer, this time window, this priority level. If your vectors live in a separate system, that’s fetch candidates, round-trip to Postgres to check the filter, re-rank, repeat. If your vectors live next to your relational data, it’s a WHERE clause.

This is the actual case for pgvector over a dedicated store — not “it’s cheaper,” but “the join you need is free when everything’s in one place.”

The diagnostic that actually matters

Before you tune anything, check what your index is actually built on and how it’s performing:

SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'your_embeddings_table';

Confirm you’re running HNSW or IVFFlat as intended, not the default sequential scan because the index never got built or got dropped in a migration.

Then check whether your distance operator actually matches what your embedding model was trained on:

EXPLAIN ANALYZE
SELECT id, embedding <=> '[your_query_vector]' AS distance
FROM your_embeddings_table
ORDER BY distance
LIMIT 10;

If this is doing a sequential scan instead of using your index, or if results look confidently wrong rather than absent, that’s usually a distance-metric mismatch — cosine operators against a model trained for dot-product comparison, or vice versa. It doesn’t error. It just quietly returns worse neighbors.

The practical shape of a fix

• Default to HNSW for agentic memory tables with ongoing writes. It has no training step and better recall at a given latency — measure before switching to IVFFlat for insert-heavy workloads.
• Match your distance operator to what your embedding model was actually trained on. Check the model card. Don’t assume cosine is always right.
• Version your embeddings. A model_version column costs nothing and saves you from silently mixing two embedding spaces after a model upgrade.
• Push relational constraints into the same query as the vector search. That join is the capability you’re paying Postgres for — use it.

The mental model

The question isn’t “which vector database is best.” It’s “does the database I’m already running, backing up, and operating handle this.” For most teams building their first agentic RAG pipeline, it does — and skipping a second system means skipping an entire category of operational surface area: one less thing to monitor, back up, and reason about failure modes for.

Reply and tell me: are you running a separate vector database today, and if so, what pushed you there? I read every reply.

— Gio