Why Vector Storage

Once you embed text into a vector — a list of, say, 768 numbers that captures meaning — you face a deceptively hard question: given a user's question vector, how do you find the most similar stored vectors fast, when you might have millions of them? This is the nearest-neighbor search problem, and it is the reason vector storage exists as its own discipline.

A normal index won't do it

A relational index — a B-tree on a nvarchar or int column — is built for exact lookups and ordered ranges. "Find rows where Status = 'Active'," "give me everything between two dates." It works because the values sort along one dimension and the tree narrows the search at each level.

Embeddings break every assumption that index relies on. There is no meaningful order across 768 dimensions, and "similar" is not "equal" — two passages about the same topic have no characters in common yet sit close together in vector space. You can't WHERE embedding = @q, because nothing will ever match exactly. What you actually need is "closest," not "equal," measured across all 768 dimensions at once. No B-tree expresses that query.

What "closest" means

Similarity between vectors is a distance. The most common measure for text embeddings is cosine distance — the angle between two vectors, ignoring their length — because embedding models encode meaning in direction, not magnitude. Two vectors pointing the same way are near 0; opposite directions approach 2. LyraLearn uses exactly this: it retrieves with VECTOR_DISTANCE('cosine', …) and ranks chunks from smallest distance up.

The honest, naive way to find the nearest neighbors is brute force: compute the distance from the query vector to every stored vector, sort, take the top K. It is perfectly accurate. The problem is cost — every search touches every row, so a corpus of a few thousand vectors is instant, but ten million vectors per query becomes a real workload. This linear scan is the baseline that vector indexes (next lesson) try to beat.

Where the vectors live

You have two architectural choices. Run a dedicated vector database (Pinecone, Qdrant, Milvers, Weaviate) as a separate service, or store vectors inside your existing database alongside the relational data. For most enterprise and public-sector teams the second is the pragmatic win: no extra service to deploy, secure, back up, and keep in sync with the source rows.

LyraLearn is the worked example. Each lesson chunk's embedding lives in a SQL Server 2025 vector(768) column in the same table as the lesson text, title, and module. One database, one backup, one security boundary — relational and semantic data never drift apart. The rest of this module explains how that works and when it is the right call.