Choosing a vector/search store
Practice this questionOverview
- Pinecone, Qdrant, Weaviate, pgvector, MongoDB Vector Search, Elasticsearch, and OpenSearch provide different ways to store and retrieve vector-backed knowledge.
- Some are dedicated vector services; others extend databases or search engines you may already operate.
- The best choice depends on your workload and team, not a universal winner.
Why this matters
Search infrastructure must fit your filters, data lifecycle, scale, operations, and budget.
An everyday example
Choose a small company filing cabinet, a managed archive, or a specialist library based on actual needs.
A technical example
A PostgreSQL application can start with pgvector and tenant-aware joins; an Atlas application can keep document data and vectors together.
How it works
- Build the same evaluation corpus/query set
- Test filtered recall, latency, update/deletion behavior, and cost
- Assess backups and access control
- Choose the least burdensome adequate option.
Architecture and flow
Requirements + existing platform → benchmark candidates → choose index/storage → ingestion + retrieval services.
The insurance assistant example
An insurer already using Atlas may start there; a separate high-volume semantic service might justify dedicated vector infrastructure.
When to use it
Choose a new store only when its capabilities solve a measured gap.
When to avoid it
Avoid deploying multiple vector stores for one corpus without a clear migration or redundancy reason.
Interview answer
“I select the store using filtered recall, lifecycle consistency, latency, operating burden, and total cost, while considering our existing database.”
Benefits, trade-offs, and production considerations
Verify the selected edition, region, version, and service limits. ANN query behavior, filter execution, hybrid features, and backups differ and evolve.
| Store | Core idea and strengths | Weaknesses/trade-offs | Choose when / avoid when |
|---|---|---|---|
| Pinecone | Managed retrieval infrastructure with vector and other search capabilities | Service cost and external dependency; evaluate portability and region controls | Choose to reduce infrastructure operation; avoid if approved self-hosting or local transactional joins are required |
| Qdrant | Vector-focused engine with payload filtering; managed and self-operated options | Self-operation adds backup, scaling, and capacity work | Choose for vector workloads needing flexible deployment; avoid if an existing DB already meets needs cheaply |
| Weaviate | Object-oriented knowledge storage with semantic/hybrid search integrations | Modules and schema choices can add system complexity | Choose when integrated search/object features fit; avoid installing unused components |
| pgvector | PostgreSQL vector extension; integrates with SQL data and access controls | Vector traffic competes with transactional resources unless isolated; tune ANN/filter behavior | Choose for SQL-heavy teams and moderate integrated workloads; isolate or move when benchmarks show contention |
| MongoDB Vector Search | Vector retrieval alongside MongoDB documents and metadata | Search index provisioning, synchronization, and capacity need attention | Choose for MongoDB document workflows; avoid assuming ordinary DB indexes automatically index vectors |
| Elasticsearch | Rich lexical relevance, filters, and vector search in a search platform | Cluster sizing, mapping, and relevance tuning require expertise | Choose when mature search already exists; avoid a heavy new cluster for a tiny semantic corpus |
| OpenSearch | Search platform with vector capabilities and deployment options | Engines, plugins, and managed editions have distinct limits | Choose when its existing search/cloud environment fits; benchmark version-specific ANN behavior |
- A useful selection exercise: 10,000 private policy chunks, PostgreSQL already deployed, five queries/second often justify trying pgvector first. Large dedicated semantic workload with a small operations team may justify managed vector infrastructure.
- These are starting hypotheses, not capacity guarantees.