Before you spin up a dedicated vector database, consider what PostgreSQL with pgvector can already do.
The case for a dedicated vector store
Dedicated vector databases — Pinecone, Qdrant, Weaviate — are optimized for one thing: approximate nearest-neighbour search at scale. They have good tooling, managed infrastructure, and are genuinely the right choice when you have tens of millions of vectors and strict latency requirements.
The case for pgvector
For most applications, you don’t have tens of millions of vectors yet. You have tens of thousands, or maybe a few million. And you already have PostgreSQL running.
pgvector adds vector storage and similarity search to PostgreSQL. You get:
- HNSW and IVFFlat indexes for fast approximate search
- Exact nearest-neighbour search for small datasets
- The full power of SQL alongside your vector queries — filter by metadata, join to other tables, run in a transaction
The operational cost is zero if you’re already running Postgres. You don’t add a new service, a new SDK, a new monitoring story, or a new failure mode.
When to migrate
The honest answer: when you measure that pgvector is actually the bottleneck. Not when a benchmark from a vector database vendor suggests it might be, but when profiling your actual workload shows it.
Most teams who’ve migrated to a dedicated vector store have done so because of organizational reasons (team expertise, vendor relationship) rather than technical necessity.
Start simple. Move when the data tells you to.
