Vector Databases and Embeddings, Explained for Your First AI Feature

If you're building your first feature that needs to find "things similar in meaning" rather than "things matching an exact keyword" — a support search, a recommendation feature, the retrieval half of a RAG pipeline — you'll run into embeddings and vector databases almost immediately. Both are simpler than the vocabulary suggests.

An embedding is a list of numbers, typically a few hundred to a few thousand of them, produced by a model that's been trained to place similar meanings near each other in that numeric space. The sentences "the cat sat on the mat" and "a kitten rested on the rug" would produce embeddings that are numerically close together, even though they share almost no words in common, because an embedding model captures meaning, not exact text.

"Close together" is measured with a distance calculation — cosine similarity is the most common — that gives you a single number for how similar two embeddings are. Finding the most relevant document for a query becomes: embed the query, then find which stored embeddings are closest to it by that measure.

A vector database exists because doing that comparison against every single stored embedding, one at a time, gets slow fast once you have more than a few thousand documents. It uses an indexing structure built specifically for approximate nearest-neighbor search — trading a small amount of accuracy for a large speedup — so a similarity search across millions of embeddings returns in milliseconds instead of scanning everything sequentially.

You don't need a dedicated vector database for every project — a regular database with a vector extension, or even an in-memory search for a small enough dataset, is often the right amount of infrastructure for a first version. Reach for a purpose-built vector database once your document count or query volume actually makes the simpler option too slow, not before.