Here is the number IBM buried in a topics page: vector-database adoption grew 377% year over year in 2025 — the fastest of any technology attached to large language models. That figure is doing a lot of work. It is telling you that the plumbing of the current AI wave is not the model. It is the index. And an index, stripped of its marketing, is a very old piece of computational geometry: given a point, which stored point is nearest? Everything a vector database sells you — RAG, semantic search, “AI-powered recommendations” — is a wrapper around that single question, asked in a space with hundreds or thousands of dimensions instead of two.

So let us do what this desk does: ignore the product, and derive the structure underneath it. Once you see the geometry, the tool stops being magic and becomes something you can defend in a review.

←TODAY: A “smartphone” query returns “cellphone” and “mobile device” because their embeddings sit in the same neighbourhood, not because a keyword matched.
→3012: The models will be forgotten; the partition of meaning-space they carved will be the archaeological layer, the map of what one civilisation thought was close to what.
Fulcrum: Semantic search only feels new because we stopped noticing that “nearest” is a geometric claim — and geometry does not expire when the vendor does.

What it is: A vector database stores data as fixed-length arrays of numbers — embeddings — where each dimension is a learned latent feature rather than a column you named. In IBM’s own worked example, “cat” becomes a 3-dimensional vector like [0.2, -0.4, 0.7]; “dog” lands nearby; “car” and “vehicle” collapse onto almost the same point despite sharing no letters. The database’s whole job is to take a new query vector and return the stored vectors closest to it, ranked by a similarity metric — cosine, Euclidean distance, or a raw dot product — in milliseconds, across millions of points. That is it. Not exact-match retrieval on tokens (the relational-database model), but proximity retrieval in a continuous space.

Why it works: The moment you say “return the nearest stored point,” you have described a Voronoi partition. Every stored embedding is a seed; the space silently divides into cells, one per seed, where a cell is exactly the region of query-space for which that seed is the closest answer. PAZ’s own Voronoi concept panel makes the point plainly: a Voronoi diagram is nothing but the geometric answer to “which seed is nearest to where” — the same math that packs trabecular bone, lays out cell towers, and, since John Snow’s 1854 Broad Street map, decides which resource a location reaches first. A query resolves by finding which Voronoi cell it fell into. The dual, the Delaunay triangulation, connects seeds that share a cell wall — and that dual is the secret to doing this fast.

Because the brutal truth in high dimensions is the curse of dimensionality: comparing a query against all N stored vectors is O(N·d), and in a 1,536-dimensional embedding space, brute force does not scale. So vector databases cheat, honestly, with approximate nearest-neighbour (ANN) search. The dominant method, Hierarchical Navigable Small World (HNSW) graphs, builds a layered proximity graph — close to a Delaunay graph — and exploits the small-world property Watts and Strogatz described in Nature in 1998: a graph can have both tight local clustering and short global paths. You enter at a coarse top layer, greedily hop toward the query, and descend. You reach the neighbourhood in a logarithmic number of steps instead of scanning everything. Locality-sensitive hashing (LSH) is the older cousin — hash functions built so that near points collide on purpose. And product quantization (PQ) compresses each vector into a short code that preserves relative distance, so a billion vectors fit in memory. Three specific geometric tricks; one geometric question.

Origins: None of this was invented for AI. Georgy Voronoy formalised the cells in 1908; Boris Delaunay published the dual triangulation in 1934. Nearest-neighbour search as a computing problem is decades old; Indyk and Motwani gave LSH its theoretical footing in 1998. The compression came from INRIA: Jégou, Douze and Schmid published product quantization for nearest-neighbour search in 2011. HNSW is Malkov and Yashunin, 2016. What changed was the source of the vectors. Mikolov and colleagues at Google shipped word2vec in 2013 and showed embeddings could carry meaning geometrically — king minus man plus woman lands near queen. Once transformers made those embeddings cheap and good (the attention operator PAZ’s concept panel derives, O(n²·d) and all), the fifty-year-old geometry of nearest-neighbour search suddenly had a business model. The 377% is the sound of old math finding new demand.

In practice: A Zurich studio does not care about e-commerce recommendations. It cares that its last decade of project knowledge — SIA-norm interpretations, tender responses, the reasoning behind a facade detail — is trapped in PDFs and nobody can find the relevant precedent under deadline. That is the exact shape RAG solves: embed the corpus, store the vectors, and let a query pull the three most semantically relevant passages to ground an LLM’s answer. IBM’s own write-up stresses that a well-built agent returns the source document and page number for verification, and that hybrid search can constrain a semantic query to a date range or category through metadata filters — the difference between a citable answer and a confident guess. IBM also notes teams usually start with a general embedding model — IBM Granite, Meta’s Llama-2, Google’s Flan — then specialise it on their own data. PAZ’s knowledge pyramid runs on precisely this: the embed stage turns distilled articles into vectors so the writer’s brief surfaces genuinely on-topic prior work. Pair it with vendor-agnostic exchange — Speckle for the model data, EPFL’s open IFC work for the standard — and the office owns its retrieval layer instead of renting it. Monday move: take fifty of your practice’s strongest past documents, embed them with an open model, and run one honest nearest-neighbour query — “how did we detail cold-bridge at a cantilever balcony?” — to see whether the closest returned passage is actually the right precedent. If it is not, your embedding model, not your archive, is the problem.

One caveat stated plainly, because the vendor pages soften it: nearest-neighbour retrieval is fact-finding, not comprehension. IBM concedes it directly — ask a vector database to summarise the whole corpus and it fails, because there is no “nearest” to a thematic overview, and you are better off with a list index that reads everything. Similarity is a local geometric operation; global understanding is not one query away.

And here is the durability warning, from a desk that has watched plugins go dark. An embedding is a point whose coordinates were assigned by a model you may not have in ten years. Store the vectors and lose the model, and you are holding a Voronoi partition of a space you can no longer re-enter — a map with no legend. The geometry survives; the meaning does not, unless you keep the recipe. Record which embedding model and version produced each vector, next to the vector. The distance metric is eternal. The encoder is not.

Hack: Rank an archive by cosine proximity to a query and pull the single closest passage — the entire retrieval layer, before any database dresses it up. This is nearest-neighbour search with the geometry showing: dot the normalised vectors, take the largest, that is the winning Voronoi cell.

import numpy as np
def nearest(q, db):
    sims = (db @ q) / (np.linalg.norm(db, axis=1) * np.linalg.norm(q))
    return int(sims.argmax()), float(sims.max())

Swap the toy arrays for real embeddings and you have understood what HNSW spends its cleverness accelerating. Once this returns the right neighbour on fifty documents, you have earned the right to reach for a real index; before it does, the fancy database only fails faster.

Source: ibm.com