Put like near like
There is one performance idea that never stops paying, from silicon to object stores, and it fits in four words: put like near like. Arrange data so that things wanted together sit together. Most of the speed you have ever gotten for free came from someone honoring that instinct at a layer you never saw.
The same trick at three altitudes
Down at the metal, a CPU never fetches one byte. It fetches a cache line, sixty four bytes of neighborhood, betting that if you wanted one you will want the next. Code that walks arrays in order wins that bet millions of times per second. Code that chases pointers across the heap loses it just as often, and no compiler can fully save it.
In analytics, the same bet wears file layout. Sorting or clustering a table so that rows sharing a customer, a date, a region live in the same files means a query about that customer touches three files instead of three hundred. Techniques with fancy names, Z-ordering among them, are ways of preserving neighborliness across more than one column at once: a space-filling curve walks the multi-dimensional space so that nearness in the data becomes nearness on disk.
In vector search, neighborliness is the entire product. An index for embeddings is a machine for answering one question fast: what sits near this point? The structures that won, clustered cells and navigable graphs, are both ways of physically grouping semantic neighbors so a query touches a neighborhood instead of a corpus.
Why the bet keeps winning
Every layer of the machine moves data in units bigger than what you asked for: cache lines, pages, blocks, files, network frames. That is not an accident; it is the only way to amortize fixed costs. Which means every fetch is a bet that the neighborhood matters. Layouts that honor the bet get their neighbors for free. Layouts that ignore it pay full price per item, forever.
The instinct even explains the exceptions. Write-heavy systems sometimes scatter on purpose, accepting worse reads to avoid rewriting neighborhoods on every insert; then a background process regroups things later. That is not a violation of the law. It is a payment plan.
The takeaway
When something is slow and the math says it should not be, ask the locality question before the algorithm question: what does this access pattern look like from the machine's side, and do the things wanted together actually live together? Rearranging data is often cheaper than rewriting code, and it is the one optimization that helps every layer below you at once.