Vector Database

It finds the closest match, not the same one

The kind of database we normally use pulls back rows that match a condition exactly — a person whose name starts with "J," a product priced under ten dollars. Off by even one character and it comes up empty.

A vector database asks a different question: "give me the ten closest to this set of numbers." That lets a document stored as "refund policy" get found by a question like "how do I get my money back" — because the two pieces of text land in nearby spots once embedded.

Results come back ranked, each with a score showing how close it is. That score lets you filter out anything too far away.

It narrows to a neighborhood instead of checking everything

If a million items are stored, measuring the distance a million times for every single question is far too slow. So the system builds a map of neighborhoods ahead of time, as items go in. A common approach links neighbors together into a web, then, at search time, starts from any point and keeps hopping to a slightly closer neighbor until it lands near the destination.

This runs tens to hundreds of times faster than checking everything. In exchange, it occasionally misses the true best match. That's why this kind of search gets called "approximately finding the closest match," with a dial that controls how thoroughly it looks around — look more carefully and it gets more accurate, and slower.

Documents get cut and converted before they go in

Documents don't get stored whole. Turn one long document into a single set of numbers and the content gets flattened — you're left with roughly what it's about, and the details disappear.

So documents get split into paragraphs or sections first, and each chunk gets its own embedding stored separately. Cut the pieces too small and context gets severed; cut them too large and the focus gets blurry. Choosing that chunk size has a real, outsized effect on how well the whole thing performs.

Each chunk gets stored alongside information like the original text, its source, and when it was written. That information matters later, for citing a source in an answer or excluding an outdated document.

It works together with filtering

Searching by meaning alone often isn't enough — sometimes you need a condition, like "only documents from this year" or "only from this department." Most vector databases can narrow the field first using that stored information, then search for closeness within what's left.

They often get mixed with the older approach of checking for an exact word match too, since meaning-based search tends to be weak on anything that has to match exactly — a product number, a person's name. Combining both sets of results and re-ranking them together is common in real deployments.

Where it gets used

The most common use is a system where an AI answers using our own material. A question comes in, a few relevant passages get pulled from the vector database first, and those passages get handed to the model along with the question to build an answer. That's what lets a model handle company policy or recent material it was never trained on.

The same setup shows up for recommending similar products or articles, catching near-duplicate documents, and finding a photo using another photo.