When SQL Beats a Pure Vector DB

The boring win: one database

If you already run Postgres for the relational part of your app, putting vectors next to the rows they describe collapses two systems into one. You stop duplicating ids, you stop syncing two stores, your transactions cover both, and your backup story gets simpler.

Where pgvector specifically wins

Heavy structured filtering. Postgres planners are decades ahead at combining 'WHERE tenant = X AND created_at > Y' with a vector ranking.
Joins on retrieval results. 'Find the 20 nearest chunks, then join their authors and click counts' is one query, not three.
Existing ops muscle. Backup, replication, monitoring, IAM, point-in-time recovery — all the boring infrastructure already exists.

Where Chroma / Pinecone / Weaviate still win

Pure vector workloads at huge scale (>50M vectors) — dedicated stores have spent more engineering on ANN.
Multi-vector and hybrid built-in — Weaviate and Vespa ship more retrieval primitives out of the box.
You do not run Postgres yet — adopting Postgres just for pgvector is heavy.

For most teams under 10M chunks who already have Postgres, pgvector is the right default in 2026.

Code

Cost-of-ownership sketch·text

Pure vector DB:
  + Best ANN performance at scale
  + Best multi-vector / hybrid primitives
  -- 2 systems to back up, monitor, secure, sync
  -- ID/metadata duplication

pgvector:
  + 1 system, 1 backup, 1 IAM model
  + Joins, transactions, structured filters for free
  + Existing ops muscle
  -- Slower than dedicated stores past ~10M vectors
  -- Less hybrid scaffolding (must build it yourself)

When SQL Beats a Pure Vector DB

The boring win: one database

Where pgvector specifically wins

Where Chroma / Pinecone / Weaviate still win

Code

External links

Exercise

Progress

Comments 0