40.9K
JGThe Simple Mental Model
pgvector = Postgres with embeddings
Vector DB = search engine for embeddings
Both work.
Trade-offs are scale, latency, and operations.
⸻
What pgvector Gives You
• One datastore (SQL + metadata + embeddings together)
• ACID transactions + mature Postgres ecosystem
• ANN search (HNSW / IVF) built in
• Cheapest and simplest if you already run Postgres
Great when search is part of your system, not the whole system.
⸻
pgvector Limits
• Mostly vertical scaling
• High QPS search can compete with OLTP workload
• Needs tuning at scale
• Harder beyond tens of millions of vectors
It’s “good enough” — not infinite scale.
⸻
What Dedicated Vector DBs Give You
(Pinecone, Qdrant, Milvus, Weaviate, etc…)
• Purpose-built ANN engines
• Horizontal scaling
• Stable latency at high QPS
• Hybrid search + filtering features
• Managed infra options
Best when search is your product.
⸻
When pgvector Is the Right Choice
✔ Few million vectors
✔ Moderate traffic
✔ Strong relational queries
✔ MVP or internal tools
✔ Already using Postgres
✔ Cost-sensitive setup
Simple. Cheap. Sufficient.
⸻
When a Vector DB Is the Right Choice
✔ Tens–hundreds of millions of vectors
✔ High QPS + strict latency
✔ Multi-tenant large workloads
✔ Search is core product value
✔ Need horizontal scaling
Performance and scale matter more than simplicity.
⸻
The Rule of Thumb
Small–medium scale → pgvector
Large-scale search system → vector DB
Start simple. Scale when needed.
⸻
Bottom line:
You don’t choose tools by hype.
You choose them by scale and workload.
Follow the series for more 🚀
⸻
Tags:
[“ai”, “llm”, “rag”, “pgvector”, “postgres”, “vectordatabase”, “pinecone”, “qdrant”, “milvus”, “systemdesign”, “mlengineering”, “mlops”, “scalableai”, “search”, “datainfrastructure”]
@jganesh.ai
