Choosing a vector/search store
Words made simple
A few useful meanings before you read the explanation.
- Vector
- An ordered list of numbers. An embedding is a vector used to represent content for tasks such as similarity search.
- Attention
- A model mechanism that combines information from different parts of the input when deciding what to produce next.
- Retrieval
- Finding and fetching information that is useful for the current question.
More words from this lesson
- Schema
- A description of the fields and value types that data should contain. It helps check that an answer has the expected shape.
- Tenant
- A customer or organization whose data must stay separate from other customers in a shared application.
- Evaluation
- Checking results against examples and clear criteria to find whether the system works well and where it fails.
- Latency
- How long a request takes to return a result. Lower latency usually means a shorter wait for the user.
- Chunking
- Dividing a long document into smaller pieces so relevant parts can be found and sent to the model.
Overview
- 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.
Can you explain it without the notes?
Choosing a vector/search store
Use your own words. Explain an example and one limitation before checking the explanation.
Check your explanation
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…
Turn this concept into a clear answer.
Practice this conceptAdapted from 13_AI.MD · “Choosing a vector/search store”. Examples are study fragments; framework behavior can depend on your version.