Retrieval needs somewhere to store vectors, IDs, and metadata. A vector database (or vector-capable store) provides ANN indexes, filters, and CRUD for embeddings at scale. Module 14.2 will deepen with FAISS and friends; here we establish the product concept and ops responsibilities.
Learning Objectives
By the end of this lesson, students should be able to:
- Define a vector database as storage + ANN search over embeddings.
- Contrast libraries (FAISS) vs managed vector DBs vs pgvector-style extensions.
- List core operations: upsert, delete, search, filter, backup.
- Explain why payload/metadata is first-class for RAG tenancy and citations.
- Identify scaling concerns: RAM, replicas, index rebuilds.
- Preview vector search as the query API over that store.
A vector database is a system optimized to store high-dimensional vectors with identifiers and metadata, and to answer nearest-neighbor queries efficiently (often via approximate indexes), optionally with filtered search.
Deployment Shapes
| Shape | Example | Tradeoff |
|---|---|---|
| Library / embedded | FAISS in-process | Fast; you own durability & HA |
| DB extension | pgvector | SQL joins; ANN maturity varies |
| Managed vector DB | Cloud services | Ops ease; vendor & cost model |
Must store
- Vector + id
- Chunk text or pointer
- Filterable metadata
Must support
- k-NN / ANN search
- Upsert & delete
- Metric choice
Nice to have
- Hybrid sparse+dense
- Multi-tenant isolation
- Snapshots / CDC
Code: In-Memory Store Sketch
Strengths
- Purpose-built for similarity
- Filters + vectors in one query
- Scales beyond numpy loops
Tradeoffs
- Another system to operate
- Index params affect recall
- Re-embed storms on model change
“A vector DB replaces our document store.” Usually you still keep canonical documents in object storage or a CMS; the vector DB indexes derived chunks. Treat vectors as a search projection, not the system of record.
Knowledge Check
- Short Answer: What query type are vector DBs optimized for? Answer: Nearest-neighbor / similarity search over vectors.
- True/False: Metadata is optional noise in RAG indexes. Answer: False—filters, tenancy, and citations depend on it.
- Multiple Choice: FAISS is best described as: (a) a library, (b) a social network, (c) a CSS framework. Answer: (a).
- Short Answer: Name one vector DB deployment shape. Answer: Embedded library, DB extension, or managed service.
- True/False: Upsert/delete matter for fresh knowledge bases. Answer: True.
- Multiple Choice: System of record for docs should usually be: (a) only ANN graph, (b) canonical doc store + vector projection, (c) browser cookies. Answer: (b).
- Short Answer: Why does model change stress a vector DB? Answer: All vectors must be re-embedded and re-indexed.
- True/False: Brute-force search scales forever. Answer: False—use ANN at scale.
- Multiple Choice: Next lecture: (a) Vector Search, (b) Vol. 1 only, (c) printers. Answer: (a).
- Short Answer: What does filtered search combine? Answer: Metadata predicates with vector similarity.
Key Takeaways
- Vector DBs store embeddings + metadata for ANN retrieval.
- Choose library vs managed vs SQL-extension based on ops needs.
- Keep canonical documents elsewhere; index is a projection.
- Next: Vector Search.
Lab: Implement TinyVectorDB; then discuss which production features are missing for a 10M-chunk corpus.
Prompt: When is pgvector enough vs a dedicated vector service?
Recap: Vector databases host the searchable projection of your knowledge base. Continue with Vector Search.