A vector database stores embeddings and retrieves nearby vectors for similarity search. In retrieval-augmented generation (RAG), document chunks are embedded and indexed; a user query is embedded in the same space, then matched chunks supply context for an answer. If the embedding model places relevant passages far from the query, the database can return weak context even when the answer exists in the documents. section 3.4.3 section 4.0
A search library such as FAISS supplies vector-search capabilities; a vector database adds infrastructure for managing embeddings in a deployed application. Efficient indexes, including HNSW-based indexes, avoid scanning every vector. Attached metadata supports filters, so results can be both semantically similar and restricted by attributes such as date, category, or status. Persistence, incremental updates, and horizontal scaling address changing collections and larger deployments. section 4.5.3
Health-care policy lookup
For a policy assistant, split documents into chunks, retain each chunk’s section title and policy metadata, and generate embeddings with a medical-domain model. Create a Pinecone index whose dimension matches the model output and whose metric is cosine. Upsert each embedding with its chunk text, policy ID, effective date, and status. At query time, embed the question and request the top matches with metadata filters—for example, to restrict results to relevant active policies—before passing retrieved excerpts to an answer generator. A matching index dimension does not guarantee a useful answer: retrieval still depends on chunking, embedding quality, and current data. section 4.5.4 section 4.0
Table 4.2 Vector database comparison
|
Database
|
Best for
|
Key strength
|
Limitation
|
|---|---|---|---|
|
Pinecone
|
Rapid prototyping
|
Managed service, minimal setup
|
Cost at scale
|
|
Weaviate
|
Complex metadata queries
|
GraphQL integration
|
Setup complexity
|
|
Qdrant
|
High-performance filtering
|
Rust-based speed
|
Smaller ecosystem
|
|
Chroma
|
Development/testing
|
Simple Python API
|
Limited production features
|
|
pgvector
|
Existing PostgreSQL users
|
Familiar tooling
|
Limited at massive scale
|
|
Milvus
|
Massive-scale deployments
|
Cloud-native, microservices architecture, multiple index types
|
Operational complexity
|
|
Elasticsearch
|
Existing Elastic stack users
|
Adding vector search to existing infrastructure
|
Not purpose-built for vectors
|
Compare database choices against deployment needs: managed setup, metadata filtering, existing database tooling, scale, cost, and operational complexity. section 4.5.3
Treat retrieval quality as an operational concern, not a property guaranteed by the database. Check whether the right passages are returned and whether generated answers remain relevant and factual; revisit chunk sizes, embedding models, filters, and data freshness when results deteriorate. section 3.9 section 4.0
