Vector Databases — Tutorial, Use Cases and Interview Guide

How to use this guide

A vector database finds things by meaning instead of by exact words. It is the memory layer behind AI search, chatbots that answer from your documents (RAG), recommendations and duplicate detection.

If you are…	Read	You will be able to
Non-technical (business, product, sales, students)	Part A, Use cases	Explain what it is, why it matters and where it pays off
Developer or data engineer	Part A, Part B, Architecture, Production	Design and build a working semantic search or RAG pipeline
Architect or engineering manager	All, especially Choosing, Production, Interview questions	Make and defend platform choices, trade-offs and rollout plans

Part A uses no jargon. Every later section builds on it, so even engineers should skim it: it is how you explain the idea to stakeholders in an interview.

Part A — For everyone: what a vector database is

A vector database stores a numeric fingerprint of meaning for each item (a sentence, a document, a photo, a product) and finds the items whose fingerprints are closest to your question.

The problem it solves

Ordinary search matches words. Search a help centre for “I can’t get into my account” and a keyword engine looks for those exact words. It misses the article titled “Reset your password”, because no words match. A person would know they mean the same thing. A vector database lets software make that same connection.

The library analogy

• A traditional database is a library catalogue: you find a book if you know its exact title, author or ID.
• A vector database is a librarian who has read every book. You describe what you need in your own words, and they walk you to the shelf where books about that idea sit together, even if none of them use your words.

The map analogy (the key idea)

Imagine a huge map where every sentence is a pin. An AI model, called an embedding model, places each pin so that similar meanings land close together. “Reset my password”, “I’m locked out” and “can’t log in” end up as near neighbours. “Refund my invoice” lands in a different neighbourhood.

The pin’s position is a list of numbers, its coordinates. That list is called a vector or embedding. A real map has two coordinates. An embedding usually has hundreds or thousands, which is why we need a special database: finding the nearest pins among millions, in milliseconds, is hard.

[embedded content: meaning map · 3 topic clusters and one question]

The question shares no words with “Reset my password”, yet it lands among the login sentences, so those three are returned (highlighted) and billing or delivery sentences are not.

Keyword search vs meaning search

	Keyword search	Vector (semantic) search
Matches	The same words	The same meaning
“Can’t log in” finds “Reset your password”	No	Yes
Exact codes (order ID, SKU, error code)	Excellent	Weak on its own
Typos, synonyms, other languages	Weak	Strong
Explains why it matched	Easy (word highlighted)	Harder (a similarity score)

The best systems combine both. This is called hybrid search.

Where you already meet it

• Chat assistants that answer from company documents look up the most relevant passages first, then write an answer from them.
• “You may also like” in shopping and streaming apps finds items close to what you liked.
• Search by photo finds products that look like a picture you upload.
• Support tools suggest the help article or past ticket most similar to a new question.
• Duplicate and fraud checks spot records that are nearly, but not exactly, the same.

Why business leaders care

1. Better answers from your own data: AI assistants grounded in company knowledge make fewer things up.
2. Search that understands customers: fewer “no results” pages, more self-service, fewer support tickets.
3. Personalisation without hand-written rules: similarity replaces long lists of if-then rules.

What it is not

• It is not a replacement for your main business database. Orders, payments and customer records still live in a normal database. The vector database holds fingerprints that help you find things.
• It is not magic accuracy. Results are only as good as the embedding model, the data and how it was split into pieces. It needs measuring, like any other system.

Part B — For engineers: how it works

A vector database stores high-dimensional vectors with metadata, and answers k-nearest-neighbour (kNN) queries fast by using an approximate nearest neighbour (ANN) index. It trades a little recall for orders of magnitude less latency.

1. Embeddings

• An embedding model maps an input (text, image, audio, code) to a fixed-length vector, for example 384, 768, 1024 or 3072 numbers. Similar inputs map to nearby vectors.
• The same model must embed both the documents and the queries. Vectors from different models live in different spaces and can’t be compared.
• Changing the model means re-embedding everything. Plan for it: store the model name and version next to each vector.
• Dimension is a trade-off. More dimensions can capture more nuance, but cost more memory, storage and query time. Some models let you request fewer dimensions.
• Chunking: long documents are split into chunks (for example a few hundred tokens, with some overlap) before embedding. One vector per whole 50-page PDF blurs every topic into one point. Chunk size is one of the biggest levers on result quality.

2. Measuring “close”

Metric	Measures	Use when
Cosine similarity / distance	Angle between vectors, ignoring length	Default for text embeddings
Dot (inner) product	Angle and length	Model was trained for it, or vectors are normalised
Euclidean (L2) distance	Straight-line distance	Some image and older models

Cosine similarity of vectors a and b:

\cos(a, b) = \frac{a \cdot b}{\lVert a \rVert \, \lVert b \rVert}

If vectors are normalised to length 1, cosine, dot product and L2 give the same ranking. Use the metric the embedding model’s documentation recommends, and use the same metric in the index and the query.

3. Exact vs approximate search

• Exact (flat / brute force): compare the query with every vector. Perfect recall. Cost grows linearly with data size. Fine for small collections, and the reference you measure ANN recall against.
• Approximate (ANN): an index visits only a small part of the data. You tune it for the recall your use case needs, often 0.9–0.99, at a fraction of the latency.

Recall@k = the share of the true top-k neighbours that the index actually returned. It is the main quality metric of the index itself, separate from whether the results are useful.

4. ANN index types

Index	Idea	Strengths	Weaknesses	Main knobs
HNSW (Hierarchical Navigable Small World)	Multi-layer graph; search hops from coarse to fine layers towards the query	High recall at low latency; incremental inserts; the common default	Memory-hungry (graph + full vectors in RAM); slower builds; deletes leave holes until rebuilt	M (links per node), ef_construction, ef_search
IVF (inverted file, e.g. IVFFlat)	Cluster vectors with k-means; search only the nearest clusters	Faster build, less memory than HNSW	Needs representative data to train; recall drops if data drifts; tune probes	lists (clusters), probes (clusters searched)
PQ / scalar / binary quantization	Compress each vector into fewer bits	Large memory savings; often combined with IVF (IVF-PQ)	Lossy: lower recall; usually needs re-ranking with full vectors	code size, bits per dimension
Disk-based graph (e.g. DiskANN)	Graph index kept mostly on SSD	Billion-scale on modest RAM	More complex; SSD latency	graph degree, cache size
Flat	No index	Exact; zero build time	Linear scan	—

[embedded content: HNSW search · 3 layers, greedy descent]

Search enters at the sparse top layer, jumps towards the query, then drops a layer and refines, so it touches a tiny fraction of all vectors.

Rule of thumb: start with HNSW. Move to quantization or disk-based indexes when memory cost dominates. Use IVF when build time or memory matters more than peak recall.

5. Metadata filtering

Real queries combine meaning with rules: “similar tickets, for this tenant, from the last 30 days”.

• Post-filtering: ANN top-k first, then drop rows that fail the filter. Fast, but a selective filter can leave fewer than k results, or none.
• Pre-filtering: apply the filter first, then search the matching subset. Accurate, but can fall back to slow scans.
• Filtered ANN (in-search filtering): the index skips non-matching nodes while it searches. Most mature vector databases do this. Check how yours behaves with very selective filters.

6. Hybrid search and reranking

• Hybrid search runs keyword search (BM25) and vector search, then merges the two ranked lists. A common merge is Reciprocal Rank Fusion (RRF), which scores each item by its rank in each list. Hybrid search fixes the vector weakness on exact identifiers (error codes, SKUs, names).
• Reranking takes the top 20–100 candidates and re-scores them with a slower, more accurate cross-encoder model that reads the query and each candidate together. Use it when precision in the top 3–5 results matters, as in RAG.

7. What a vector database adds over a vector library

A library such as FAISS gives you the index. A database adds everything around it: persistence, CRUD and upserts, metadata filtering, replication, sharding, backups, access control, multi-tenancy, monitoring and a query API.

Architecture: where a vector database fits

A vector database sits between two pipelines: an offline one that writes chunks and their vectors, and an online one that reads them for every question.

[embedded content: RAG architecture · ingestion and query paths around one vector database]

The top row runs when content changes; the lower rows run per request, and the vector database is the only part both share.

Ingestion path (offline)

1. Source docs: pull from wikis, file shares, ticketing or CRM systems, with each document’s permissions.
2. Parse + chunk: extract clean text, then split it into passages along headings and paragraphs.
3. Redact PII: remove personal data that the search does not need, before it is copied into a new store.
4. Embed: the embedding model turns each chunk into a vector, in batches.
5. Upsert: store the vector with metadata (document ID, chunk ID, permissions, tenant, updated time, model version), and the text for keyword search.

Query path (online)

1. Embed the question with the same model used for the documents.
2. Add filters from the signed-in user’s identity: tenant and permission groups. Never take them from the request body or the prompt.
3. Hybrid search: vector search and keyword search, merged (for example with RRF), returning about 50 candidates.
4. Rerank the candidates with a cross-encoder and keep the best 3–5.
5. Generate: the LLM answers using only those passages, and cites them.

Where it sits in the wider system

• The system of record (PostgreSQL, a CRM, a document store) stays the source of truth. The vector index is a derived copy that can be rebuilt.
• A change feed or scheduled job keeps the index fresh. Index lag is a metric you monitor.
• Retrieval sits behind your own interface, so the database, embedding model or reranker can be swapped without touching business logic.

Use cases explained

Vectors fit whenever the question is “what is like this?” rather than “what equals this?”. The table gives the quick view; the notes below explain each one in plain terms with the engineering detail.

Use case	Plain-language example	What gets embedded	How success is measured	Main pitfall
RAG (retrieval-augmented generation)	A chatbot answers HR policy questions from the company handbook	Document chunks	Answer faithfulness, retrieval recall@k, groundedness	Bad chunking or stale documents give confident wrong answers
Semantic search	“Can’t log in” finds the password-reset article	Articles, pages, products	Click-through, zero-result rate, nDCG	Misses exact codes unless hybrid
Recommendations	“Customers who liked this also liked…”	Items and user profiles	Conversion, watch time, diversity	Filter bubbles; cold start for new items
Duplicate and near-duplicate detection	Merge two support tickets about the same outage	Tickets, records, documents	Precision and recall on known duplicate pairs	One global threshold rarely fits every category
Support ticket triage	Route a new ticket like similar past tickets	Ticket text	Routing accuracy, auto-route precision	Old labels may be wrong; needs human review
Image and multimodal search	Upload a photo of a chair and find similar products	Images (and text) in one shared space	Visual relevance judged by people	Lighting and background dominate unless models are tuned
Anomaly and fraud signals	A transaction pattern unlike any normal one	Behaviour or transaction features	Precision at a fixed alert budget	Vectors only flag; rules and humans decide
Code search	“Function that retries HTTP calls” finds it without its name	Code chunks and docstrings	Developer task success	Code changes fast; index goes stale
Agent and chatbot memory	An assistant recalls a preference from last month	Conversation summaries	Relevant recall without leaking other users’ data	Privacy; strict per-user isolation needed

RAG: the use case behind most demand

Large language models know only their training data and can invent facts. RAG first retrieves the most relevant passages from your own documents, then asks the model to answer using only those passages, with citations. The vector database is the retrieval step.

What decides quality, roughly in order: the documents themselves (fresh, correct, permission-aware), chunking, the embedding model, hybrid search plus reranking, then the prompt. Teams often tune the prompt first and the data last. That is usually backwards.

Semantic search

The classic upgrade to site or product search. Users type how they talk, and the index understands synonyms and paraphrases. Pair it with keyword search so exact product codes and names still win.

Recommendations

Items and users are embedded in the same space. A user’s vector can be the average of what they engaged with, and “recommend” becomes “find nearest items”. Production systems add business rules (in stock, not already bought) as filters and mix in diversity.

Duplicate detection and entity resolution

Nearly identical records (two tickets about the same outage, two supplier entries with slightly different names) sit very close together. A distance threshold flags pairs. Tune it on labelled pairs and send borderline pairs to a person.

Support ticket triage

A new ticket’s nearest labelled past tickets give two things: few-shot examples for an LLM classifier, and a neighbour vote that works as an observable confidence signal. Project 01 in your FDE portfolio uses exactly this pattern with pgvector.

When NOT to use a vector database

• Exact lookups (an order by ID, a customer by email): a normal index is faster, cheaper and exact.
• Aggregations and reports (revenue by month): that is SQL or a warehouse.
• Tiny collections (a few thousand items): brute-force similarity in memory, or a vector column in your existing database, is enough.
• Strict-correctness decisions (approving a payment): similarity can suggest, but rules and people must decide.

Choosing a vector database

Start with the database you already run if it supports vectors. Move to a dedicated vector database when scale, latency or vector-specific features justify running one more system.

The categories

Category	Examples	Best when	Trade-off
Vector support in your existing database	pgvector for PostgreSQL, MongoDB Atlas Vector Search, Redis	Up to millions of vectors; you want joins, transactions and one system to run	Fewer vector-specific features; vector load competes with transactional load
Dedicated vector database (open source, self-host or managed)	Qdrant, Weaviate, Milvus, Chroma	Large scale, heavy filtering, quantisation, multi-tenancy at vector level	One more system to run, secure, back up and keep in sync
Fully managed vector service	Pinecone and the managed clouds of the open-source options	Small team, fast start, no operations	Vendor lock-in, data residency, cost at scale
Search engine with vectors	Elasticsearch, OpenSearch	You already run one; strong keyword plus vector hybrid search	Heavier to operate; vectors are one feature among many
Library (not a database)	FAISS	Offline batch jobs, research, embedding inside your own service	No persistence, filtering, replication or access control on its own

Questions that decide it (ask them in this order)

1. How many vectors, now and in two years? Thousands: anything works. Low millions: Postgres with pgvector is usually enough. Hundreds of millions or more: look at dedicated or disk-based options.
2. What latency and throughput? For example p95 under 100 ms at a given number of queries per second. Measure on your own data.
3. How selective are the filters? Per-tenant, per-permission and date filters stress ANN indexes. Test your hardest filter.
4. How often does data change? Frequent updates and deletes favour indexes that handle them well, and need a plan for compaction or rebuilds.
5. Do you need hybrid search? If exact terms matter, prefer a system with built-in keyword plus vector search, or plan to merge results yourself.
6. Where may the data live? Compliance can rule out a SaaS, or require a specific region.
7. Who will operate it? A managed service costs money; self-hosting costs people’s time. Count both.
8. What does the rest of the stack already use? One fewer system to secure and monitor is a real saving.

A sensible default path

1. Prototype: an in-memory library or a local Chroma or pgvector instance.
2. First production: pgvector in your existing managed PostgreSQL, with HNSW and hybrid search.
3. Scale-out: when measurements, not guesses, show limits on memory, latency, filtering or isolation, move the vector workload to a dedicated or managed vector database behind the same retrieval interface in your code.

Keep retrieval behind your own interface (a retriever or repository class). Then this migration is an adapter swap, not a rewrite.

Links point to each product’s official documentation, as of 14 October 2026. Features and licences change, so check them before deciding.

Production concerns

A demo needs an index and a query. Production needs measured quality, predictable latency, safe updates, tenant isolation and a cost you can explain.

Concern	What goes wrong	What to do
Recall vs latency	Defaults give fast but incomplete results, or slow perfect ones	Build a labelled query set; measure recall@k against a flat (exact) search; tune ef_search or probes until recall meets the target at your p95 latency budget
Memory and cost	HNSW keeps the graph and full vectors in RAM; cost grows with vectors × dimensions	Estimate: vectors × dimensions × 4 bytes (float32), plus index overhead. Use fewer dimensions, half precision or quantisation with re-ranking
Ingestion and freshness	Source documents change; the index serves stale or deleted content	Event-driven or scheduled re-embedding; content hashes so only changed chunks are re-embedded; tombstones for deletes; track index lag as a metric
Updates and deletes	Graph indexes degrade after many deletes	Plan compaction or periodic rebuilds; blue/green index rebuild with an alias switch
Embedding model upgrades	New and old vectors are not comparable	Store model and version per vector; build a new index in parallel, evaluate, then switch over; never mix models in one index
Multi-tenancy and access control	One customer’s documents appear in another’s results; RAG leaks data a user may not see	Tenant ID and permission filters enforced on the server, not in the prompt; separate collections or partitions for large tenants; test isolation explicitly
Scaling	One node runs out of memory or query capacity	Shard to spread data, replicate to spread reads; partition by tenant or time when queries allow
Hybrid quality	Exact codes and names are missed	Keyword plus vector search fused with RRF; a reranker on the top candidates
Security and privacy	Embeddings can leak information about the text they came from; PII is copied into a new store	Treat vectors as sensitive as the source; redact PII before embedding; encrypt at rest and in transit; apply retention and deletion rules to vectors too
Evaluation	Quality silently drops after a data, model or chunking change	Offline golden set (recall@k, MRR, nDCG) in CI; online signals (clicks, “no answer”, thumbs down); for RAG, also answer faithfulness
Observability	Nobody can explain a bad answer	Log query, filters, returned IDs and scores, model version and latency per request; trace retrieval and generation together
Disaster recovery	An index lost with no fast rebuild	Back up the source of truth and the embeddings; know your full rebuild time and cost

Sizing example (back-of-envelope)

10 million chunks × 768 dimensions × 4 bytes ≈ 30.7 GB for the raw vectors alone, before index overhead and replicas. Halving the dimensions, or storing half precision (2 bytes per number), roughly halves it. Quantisation can cut it much further, at some cost in recall.

Latency budget for a RAG request

A typical request spends time in four places: embedding the question, vector search, reranking, then the LLM writing the answer. The LLM is usually the largest share. Measure each step separately, so you tune the part that actually dominates.

Interview questions with model answers

Strong answers name the trade-off, give a number or a way to measure, and say what you would do next. The answers below are short versions to expand on with your own project examples.

Fundamentals

1. What is a vector database, and how is it different from a relational database? It stores embeddings and answers similarity (nearest-neighbour) queries quickly with ANN indexes. A relational database answers exact-match and range queries and aggregations with B-tree style indexes. Most systems use both: relational for the source of truth, vectors to find things by meaning.
2. What is an embedding? A fixed-length list of numbers produced by a model so that similar inputs land close together. The model’s training decides what “similar” means, so the model choice matters as much as the database.
3. Cosine, dot product or Euclidean: which and why? Use what the embedding model was trained with, usually cosine for text. With normalised vectors all three give the same ranking. Mixing metrics between index and query is a common bug.
4. Why approximate instead of exact search? Exact search compares the query with every vector, so cost grows linearly. ANN visits a small fraction for, say, 95–99% recall at far lower latency. Exact search stays useful for small data and as the yardstick for measuring ANN recall.
5. Explain HNSW. A layered graph. The top layers are sparse long-range links, the bottom layer has every node. Search starts at the top, greedily moves towards the query, and drops a layer at a time. M sets links per node (memory, recall); ef_construction sets build quality; ef_search trades latency for recall at query time.
6. HNSW vs IVF? HNSW: higher recall at low latency and easy incremental inserts, but more memory and slower builds. IVF: clusters data and searches the nearest clusters; faster builds and less memory, but needs training data and loses recall if data drifts. Product quantisation compresses either at some recall cost.
7. What is recall@k, and how do you measure it? The share of the true top-k neighbours the index returned. Run a sample of queries through both the ANN index and an exact search, and compare the result sets.
8. What is hybrid search? Keyword (BM25) and vector results merged, often with Reciprocal Rank Fusion. Keyword search catches exact identifiers; vectors catch paraphrases. Together they beat either alone on most real queries.

Design questions

9. Design a RAG system over 5 million internal documents with per-user permissions. Ingestion: connectors → parse → clean → chunk → redact PII → embed → upsert with metadata (doc ID, ACL groups, updated time, model version). Query: embed → hybrid search filtered by the user’s groups on the server → rerank top 50 → top 5 into the prompt with citations. Add evals (retrieval recall, faithfulness), freshness monitoring, and an audit log. The non-negotiable: permissions are filters in retrieval, never instructions in a prompt.
10. How would you choose chunk size? Start around a few hundred tokens with some overlap, aligned to structure (headings, paragraphs). Then measure retrieval recall and answer quality on a golden question set across two or three sizes. Too small loses context; too large blurs topics and wastes prompt tokens.
11. How do you handle updates and deletes? Upsert by a stable chunk ID; use content hashes to skip unchanged chunks; delete by document ID so all its chunks go. For graph indexes, plan compaction or periodic rebuilds. Track index lag between source change and searchability.
12. How do you migrate to a new embedding model? Never mix models in one index. Build a new index in parallel (dual-write new data), backfill, evaluate both on the golden set, switch with an alias or flag, keep the old index for rollback, then retire it.
13. Design multi-tenant vector search for a SaaS product. Options: a tenant ID filter in a shared index (cheap, but test filtered recall and isolation), a partition or namespace per tenant (better isolation and deletes), or a dedicated index for the largest tenants. Enforce the tenant on the server from the auth token, never from the request body.
14. Estimate memory for 100 million 1,024-dimension vectors. 100M × 1,024 × 4 bytes ≈ 410 GB raw, before index overhead and replicas. That points to sharding, quantisation (for example 8-bit, about a quarter of the size) with full-precision re-ranking, or a disk-based index.
15. pgvector or a dedicated vector database? pgvector when you already run PostgreSQL, data is up to the low millions, you value joins and transactions, and ops headcount is small. A dedicated system when measurements show memory, latency, filtering or tenancy limits. Keep retrieval behind an interface so you can move later.

Scenario and troubleshooting

16. Users say search results are “close but wrong”. Where do you look? In order: the query set and labels (is “wrong” measurable?), chunking, the embedding model’s fit to the domain, missing hybrid or reranking, then index recall. Fix the biggest measured gap first.
17. Search misses exact error codes and product SKUs. Classic vector weakness. Add keyword search and fuse the results, or route queries that look like identifiers straight to an exact lookup.
18. Latency jumped after data doubled. Check whether the index still fits in memory, whether filters became more selective (forcing slow scans), and ef_search or probes settings. Then shard or replicate, or quantise.
19. A RAG bot showed a confidential document to the wrong user. Stop the leak first (disable the source or the feature). Root cause is usually permissions not enforced as retrieval filters, or stale ACL metadata. Fix: server-side filters from identity, ACL sync monitoring, an isolation test suite in CI, and an incident review.
20. Results got worse after a reindex, with no code change. Suspect a different embedding model or version, a changed metric, different chunking or index parameters. This is why model version and index config belong in metadata and the golden-set eval runs before every switch.

Architect and engineering manager questions

21. How do you justify a vector database to leadership? Tie it to an outcome: higher self-service resolution, fewer “no results”, faster agent handling. Propose a small pilot with a baseline metric, a target, a cost estimate and an exit criterion. Say what you will not build.
22. Build vs buy (managed service vs self-hosted)? Compare total cost: subscription vs infrastructure plus on-call people time. Weigh data residency, lock-in and the team’s skills. A common path is managed first for speed, with an abstraction layer to keep the exit open.
23. How do you keep AI search quality from silently degrading? Golden sets in CI for every model, chunking or prompt change; online metrics and feedback; drift dashboards; owners for data freshness. Quality is a release gate, not a one-off test.
24. What risks would you put on the risk register? Data leakage across permissions, stale content, PII in embeddings, cost growth, vendor lock-in, model deprecation forcing a re-embed, and hallucination despite retrieval. Each needs a mitigation and an owner.
25. How would you staff and phase a first semantic search project? Phase 1 (weeks): a narrow use case, a golden set and a baseline. Phase 2: hybrid search, reranking and evals in CI. Phase 3: scale, multi-tenancy and SLOs. Roles: a backend engineer, a data engineer for ingestion, part-time ML or search expertise, and a product owner who owns the quality metric.

How to stand out

• Bring one real number from your own project: recall@k before and after, p95 latency, cost per 1,000 queries.
• Say “I’d measure it” and then say how.
• Raise permissions, PII and freshness before the interviewer does. That is the senior signal.

Glossary and learning path

Glossary

Term	Plain meaning
Vector / embedding	A list of numbers that stands for the meaning of an item
Embedding model	The AI model that turns text, images or code into vectors
Dimension	How many numbers are in each vector (for example 768)
Similarity / distance metric	The formula for “how close”: cosine, dot product, Euclidean
kNN	k-nearest neighbours: the k most similar items
ANN	Approximate nearest neighbour: fast search that may miss a few true neighbours
Recall@k	Share of the true top-k results that the search actually returned
HNSW	A graph index, the most common ANN index
IVF	An index that clusters vectors and searches only the nearest clusters
Quantisation (PQ, scalar, binary)	Compressing vectors to save memory, at some cost in accuracy
Chunking	Splitting long documents into smaller passages before embedding
Metadata filter	A rule applied with similarity, for example tenant or date
Hybrid search	Keyword search and vector search combined
BM25	The standard keyword relevance formula
RRF	Reciprocal Rank Fusion: a simple way to merge two ranked lists
Reranker / cross-encoder	A slower, more accurate model that re-orders the top candidates
RAG	Retrieval-augmented generation: retrieve passages, then let an LLM answer from them
Faithfulness / groundedness	Whether an answer is supported by the retrieved passages
Namespace / partition / collection	A separate area of an index, often per tenant
Upsert	Insert, or update if the ID already exists

Learning path

1. Concepts (1–2 hours): Part A and Part B of this guide. Explain the map analogy to a non-technical friend; if they get it, you do too.
2. Hands-on basics (half a day): your own AI FAQ assistant tutorial with PostgreSQL, pgvector and Gemini: embeddings, a vector column, an HNSW index and a similarity query.
3. Measure it (half a day): build 30–50 labelled questions; compute recall@k with exact search vs HNSW; change ef_search and watch recall and latency move.
4. Make it production-shaped (1–2 days): add hybrid search with RRF, metadata filters, a reranker, and a golden-set evaluation that runs in CI. Project 01 (ticket triage) in your FDE portfolio already shows filtering, neighbour voting and evaluation.
5. Compare a dedicated database (1 day): load the same data into one dedicated vector database; compare latency, filtered recall, memory and operational effort with pgvector. Write a one-page decision record.
6. Interview rehearsal: answer questions 9, 13, 15 and 21 out loud in under three minutes each, with one number from your own measurements.