Vector Databases

A vector database stores and searches embeddings — lists of numbers that capture the meaning of a piece of content. It answers "what is most similar in meaning to this?" rather than "what contains these exact words?" This is the engine behind semantic search, recommendations, and retrieval-augmented generation (RAG) for AI apps. If keyword search (Elasticsearch) finds documents with matching words, vector search finds documents with matching ideas.

Embeddings: meaning as coordinates

A model turns text (or an image, audio, etc.) into a vector — say 1,536 numbers — positioned so that similar things land close together in that high-dimensional space. "dog" and "puppy" end up near each other; "dog" and "database" far apart. Similarity becomes distance: to find things like a query, you embed the query and look for the nearest vectors.

"cheap flights to nairobi"  ─embed─►  [0.12, -0.44, 0.91, ...]
                                        find the nearest stored vectors = closest in meaning

Why it needs a special database

Nearest-neighbour search in high dimensions is hard. Computing the distance from your query to every stored vector (exact search) is O(n) over millions of high-dimensional vectors — far too slow for real time. And ordinary spatial indexes (quadtrees, R-trees) break down in hundreds of dimensions. Vector databases use Approximate Nearest Neighbour (ANN) indexes — most commonly HNSW (a navigable graph you can traverse toward the closest vectors) — that return almost the nearest results in milliseconds. You trade a tiny bit of recall for a massive speedup, which is exactly the right trade for "find similar."

Where it fits

• Semantic search — "documents about X" even when they don't use the word X.
• Recommendations — "items similar to what you liked" via their embeddings.
• RAG — the retrieval step of AI apps: embed the user's question, pull the most relevant chunks of your own documents, and feed them to the model so it answers from your data instead of guessing.
• Deduplication / clustering — group near-identical content by vector closeness.

The pattern

1. Index: chunk your content, embed each chunk with a model, store the vectors (plus metadata) in the vector DB.
2. Query: embed the query the same way, ask for the top-K nearest vectors, optionally filter by metadata, and use the results.

Most vector DBs also support hybrid search — combining vector similarity with keyword and metadata filters — because pure semantic search alone often misses exact-match needs (a product SKU, a date).

What to watch

• It's a secondary index, like search. Your source of truth stays elsewhere; you (re)embed and index into the vector store, and must re-embed when content changes.
• Embedding model matters. Query and documents must use the same model; swapping models means re-embedding everything.
• You may not need a dedicated one. Postgres with pgvector adds vector search to a database you already run — plenty for small-to-medium corpora before reaching for a dedicated store (Pinecone, Weaviate, Milvus).

What to say in an interview

Bring it up for "similar in meaning," and name the ANN trade-off:

"Search here needs to match meaning, not keywords, so I'd embed each document and store the vectors in a vector database, then embed the query and retrieve the top-K nearest. Exact nearest-neighbour is too slow at scale, so it uses an ANN index like HNSW — approximate but millisecond-fast. For a RAG feature those retrieved chunks feed the model. At small scale I'd just use pgvector in Postgres rather than a separate system."

Next up: Change Data Capture — reliably reacting to every change in your database.