Search that finds what you meant: vector databases, explained properly

Start from the failure, because everyone has lived it. A colleague asks for "the contract with the late delivery penalty". You search the archive for "penalty". Nothing. The contract says "compensation for delayed handover". The document was always there; the search could not see that two different sentences mean the same thing. Every keyword system fails this way, in every language, and it fails harder in Arabic where one root takes dozens of forms. Vector databases exist to fix exactly this failure, and they are the memory behind almost every serious AI system you have seen. Here is how they work, properly.

Step 1: meaning becomes numbers (embeddings)

An embedding model is a neural network with one job: read a piece of text and output a fixed list of numbers, typically 768 to 1,536 of them, called a vector. The training pushed the model to give similar meanings nearby numbers. "Late delivery penalty" and "compensation for delayed handover" produce vectors that are close; "annual leave policy" lands far away. Think of it as a map with a thousand dimensions instead of two: every sentence gets coordinates, and distance on the map is difference in meaning. Images, audio, and code can be embedded the same way, which is why the same machinery powers photo search and code search.

Step 2: the nearest-neighbour problem

Now your archive is a million vectors and a question arrives: embed the question, then find the stored vectors closest to it (closeness is usually cosine similarity, the angle between vectors). The naive way compares against all million, which works and is exact, but at tens of millions of vectors and thousands of queries per second it collapses. This, precisely, is the problem vector databases solve: nearest-neighbour search at scale, fast.

Step 3: the trick that makes it fast (HNSW)

The dominant index is HNSW (hierarchical navigable small world). Picture the vectors as cities and the index as a road network built in layers: a top layer of long highways between distant regions, lower layers of shorter regional roads, and a bottom layer of local streets connecting true neighbours. A search starts on the highways, gets to roughly the right region in a few hops, then descends through shorter roads until it is walking local streets around the answer. Instead of checking a million vectors it checks a few thousand, and finds the true nearest neighbours 95-99% of the time. That deliberate trade, a sliver of exactness for a thousandfold speedup, is the entire engineering soul of a vector database. The dials (how many roads per city, how wide the search walks) let you trade speed against recall per query.

What a real one does beyond the index

Production needs more than nearest-neighbour. Metadata filtering: "nearest contracts, but only this supplier, after 2024", which the database must apply without wrecking index performance. Hybrid search: combining vector similarity with classic keyword scoring, because exact codes like "INV-4471" must still match exactly. Quantization: compressing vectors to a quarter of their memory at almost no recall cost, which decides your hardware bill. And the unglamorous rest: updates and deletes without rebuilding the index, backups, and access control. The index is the soul; this list is the job.

The 2026 landscape, measured

Read that chart carefully, because the slowest bar is the usual right answer. pgvector lives inside Postgres: your documents, their metadata, and their vectors share one database, one transaction, one backup, and SQL filtering, with no second system to operate. Benchmarks published this year show Postgres with the pgvectorscale extension sustaining 471 queries per second at 99% recall on 50 million vectors, an order of magnitude beyond what most businesses will ever need. The practical decision tree in 2026 is one sentence: pgvector if you run Postgres and have under ~50M vectors; Qdrant when vector search is the product itself; Milvus only when you are genuinely at hundreds of millions.