toolcall() ← all concepts

// concept · pgvector

You probably don't need a vector DB.

The reflex when you build RAG is to spin up a separate vector database service. But the Postgres you already run can do similarity search — and keep your vectors right next to your data.

// the reflex vs the alternative

You add retrieval to an app and the instinct is to reach for Pinecone, Qdrant, Weaviate, or Milvus — a whole new service to run, sync, and back up. For most apps, you don't need it yet. Postgres plus the pgvector extension already does vector similarity search, inside the database you're probably already using.

# the usual setup Postgres + a separate vector DB # two systems to sync # what pgvector gives you Postgres + pgvector # one system, vectors live next to rows

The real win

When vectors live in the same table as your data, one query can do retrieval and business filtering — no second service, no syncing IDs, no "fetch from the vector DB, then re-fetch the rows from Postgres" round trip. Filter by user, order by similarity, all in a single statement, inside a transaction:

SELECT id, body FROM documents WHERE user_id = 42 -- relational filter ORDER BY embedding <=> $query_embedding -- vector similarity LIMIT 5;

That <=> is cosine distance. You get ACID transactions, JOINs, point-in-time recovery, and one backup story — for free, because it's just Postgres.

How it works

pgvector adds a vector column type, a set of distance functions (cosine <=>, L2 <->, inner product <#>, and more), and approximate-nearest-neighbor indexes so search stays fast as the table grows:

HNSW # better query performance, slower build, more memory IVFFlat # faster build, less memory, lower query performance
It's not zero-config at scale. You still choose HNSW vs IVFFlat, tune the recall-vs-speed knobs, and index the column you filter on. pgvector gives you the levers — it doesn't remove them. (Tip: halfvec and binary quantization cut memory when vector counts climb.)

When a dedicated DB actually wins

This is "start simple," not "vector DBs are bad." pgvector with HNSW matches or beats dedicated engines around the 1M-vector mark. The practical crossover lands roughly past ~10 million vectors, or under very high sustained query volume, where purpose-built engines and distributed sharding pull ahead.

That's where Pinecone, Qdrant, Weaviate, and Milvus earn their keep — fastest managed time-to-production, filtered-search QPS, hybrid and multi-tenant features, horizontal scale. Real wins, at a scale most apps haven't hit.

# the decision rule start Postgres + pgvector # the default for most apps graduate dedicated vector DB # when you cross ~10M vectors / very high QPS

Sources: pgvector — README (indexing, distance, types, filtering) · Supabase — vector columns & combined queries · Nile — pgvector (ACID, JOINs, filtering) · AWS — IVFFlat vs HNSW · SecondTalent — when each wins (~10M crossover)

One concept a week. Free.

The deeper, copy-paste version of each ToolCall short — in your inbox.

// total: 0.00 · spam: void · unsubscribe: one click