Vector Databases
Match the workload to the right vector database
“A startup replaced their Pinecone plan ($700/month) with pgvector after discovering they only had 2M vectors — well within pgvector's sweet spot. With pgvectorscale, they got 471 QPS at 99% recall, 11x Qdrant on the same hardware, at $0 additional infrastructure cost since they already ran PostgreSQL.
Vector Database Architecture
Why Regular Databases Cannot Do Similarity Search
A traditional SQL WHERE clause finds exact matches. But RAG needs approximate nearest neighbor (ANN) search — finding the K vectors closest to a query vector in high-dimensional space.
HNSW (Hierarchical Navigable Small World) graphs solve this. The algorithm builds layers of connections between vectors, where higher layers connect distant neighbors and lower layers connect close neighbors. Query time is O(log n) with >99% recall.
If you already run PostgreSQL, pgvector is your default. With pgvectorscale, it achieves 471 QPS at 50M vectors — 11x faster than Qdrant on the same hardware. No extra infrastructure, no new ops burden, no data synchronization headaches.
Enterprise Skills Bridge: HNSW is to vector search what a B-tree index is to SQL. Same principle: trade extra storage and write overhead for dramatically faster reads. You've built B-tree-backed search systems your entire career — pgvector is the same skill applied to 768-dimensional similarity.
You've spent years tuning B-tree indexes on SQL Server and Oracle. HNSW is the same concept applied to high-dimensional space: trade storage and write overhead for fast reads. The tuning discipline transfers: monitor index build time, watch for index bloat on high-write workloads, and benchmark recall vs query latency trade-offs the same way you'd benchmark SQL index selectivity.
Concept Matcher
Vector Databases
1 question • ~2 min
Tip: Complete the learn sections first for the best score.