What a vector database does
An embedding turns text into coordinates. A vector database finds the nearest neighbors of a point, fast, at millions of points.
An encoder reads a piece of text and outputs a few hundred numbers: coordinates in a space where distance approximates meaning. “Vollmilch 3,5%” and “H-Milch 1l” land close together, “Katzenfutter” lands far away, and a typo like “coca-colla” barely moves the point, because the position is computed from the whole string rather than looked up word by word.
A vector database stores those points and answers one question fast: which stored points are nearest to this new one? Comparing against every point stops scaling somewhere in the millions, so the indexes are approximate. HNSW, the common one, builds a navigable graph of neighbors and walks it, trading a sliver of recall for a speedup of several orders of magnitude. The engineering that matters day to day is less exotic: metadata filters, index rebuilds, and keeping embeddings in sync with the source of truth as documents change.
An opinion from running these in production: if your corpus is a few hundred thousand chunks, you may not need a dedicated vector database at all. Postgres with pgvector holds up far longer than the marketing of specialized stores suggests, and it is one less system to run. We have removed more vector databases than we have installed.