The Uncomfortable Truth
If your vector collection has fewer than 5 million vectors, you almost certainly don't need a dedicated vector database. PostgreSQL with pgvector will give you identical recall at query latencies under 50ms. And you already know how to operate PostgreSQL.
We've deployed both dedicated vector databases (Pinecone, Qdrant) and pgvector across client projects. Here's what we've learned:
Under 1M vectors: pgvector with HNSW indexing. Query latency: 5-15ms. Zero additional infrastructure. Your existing PostgreSQL backup, monitoring, and failover strategies just work.
1M-10M vectors: pgvector still works, but you'll want to tune HNSW parameters and may need a dedicated PostgreSQL instance. Or use a managed vector database if your team doesn't want to tune PostgreSQL.
Over 10M vectors: This is where dedicated vector databases earn their keep. Sharding, distributed search, and sophisticated indexing algorithms (like Pinecone's proprietary index) provide meaningful advantages.
Why Teams Over-Adopt
Three reasons. First, hype. Vector databases are exciting new technology and engineers love new technology. Second, premature optimization. Teams architect for 100M vectors when they have 50K. Third, vendor marketing. Every vector database company tells you that you need a vector database.
The Real Costs
A dedicated vector database adds: another service to monitor, another failure mode in your architecture, another vendor relationship to manage, another set of credentials to secure, and another migration to plan when you inevitably switch providers.
pgvector adds: one PostgreSQL extension and an index creation statement.
Our recommendation: Start with pgvector. Migrate to a dedicated vector database when — and only when — pgvector becomes your bottleneck. In 18 months of enterprise AI consulting, that's happened exactly once.