GINGER: Spicing Up Graph-Based Vector Search: what it means for business leaders

Google Research has open-sourced Ginger, an in-memory vector search library that led throughput on 13 of 14 public benchmarks by combining one nested quantization code with lossless graph compression, and it merits a pilot against our own embeddings.

1. What the method is

Ginger is an open-source, in-memory C++ library from Google Research for graph-based approximate nearest neighbor search, the retrieval step underneath most embedding search. It is also the official open-source implementation of the PiPNN II index builder, with Vamana offered as an alternative. Two components are new. Nested TurboQuant stores one code per vector for two jobs: the leading 4 bits per coordinate steer the graph search, and the remaining bits, usually reaching 10 or 12 in total, rerank the results at close to 32-bit float accuracy. AdaptiveGap is a lossless codec that packs the gaps between neighbor IDs into fewer than eight bits when they are small while keeping fast SIMD decoding. Around these sit a fast integer scoring kernel, PCA projection or a tuning-free prefilter for high-dimensional embeddings, and graph reordering, all written in portable SIMD code.

2. Why the method was developed

The authors name three practical limits on graph indexes: memory bandwidth during search, the memory needed to host the index, and build time. Their earlier PiPNN work addressed build time, cutting billion-scale construction from hours to tens of minutes, so Ginger targets the other two. Search needs two conflicting precisions: a compact code that is cheap to load for the thousands of candidates scored per query, and float-level accuracy for the final rerank. The usual recipe keeps a second code or the original vectors, which wastes memory. Product quantization suits this access pattern poorly because its lookup tables are expensive to load relative to scoring one point. The graph itself is also costly: a 96-dimensional vector takes 144 bytes at 12 bits per coordinate, while its flat adjacency list takes 260 bytes. Existing codecs such as StreamVByte round every gap up to whole bytes.

3. Who should care

Our search and platform engineers are the first audience, since anything running retrieval-augmented generation, semantic search or recommendations at scale depends on this layer. Whoever owns infrastructure spend should care too, because an in-memory index sets how much RAM we rent, and query throughput sets how many machines we need. ML engineers gain room to use larger embeddings, as the biggest gains are on high-dimensional data. Data engineering would benefit from shorter builds if we re-embed or reindex often. Anyone buying a managed vector database should ask vendors whether these techniques are coming and how their numbers compare on our data. Teams with a few million vectors and no latency or cost pressure can ignore this for now: on the smallest datasets every library tested finished building within two minutes, so there is less to win.

4. How the method works

A random rotation makes each vector coordinate roughly Gaussian, so a single non-uniform codebook serves every coordinate. Each 4-bit interval is then split into finer sub-intervals with its own refinement codebook. Because Gaussian sources can be refined in stages with little loss, the nesting costs almost no accuracy. Navigation codes and refinement codes sit in separate arrays, so graph traversal loads no extra bytes. Scoring keeps the 16-entry codebook in a vector register, and one AVX-512 shuffle performs 64 lookups; reranking computes centroids from piecewise-cubic polynomials in registers, which roughly halves 10- and 12-bit rerank latency. High-dimensional search also works on PCA-projected coordinates or rejects candidates early using a prefix of the code. For the graph, recursive partitioning gives connected vertices nearby IDs, which shrinks the gaps, and each neighbor list selects whichever of 16 bit-width modes encodes it smallest.

5. How it was evaluated

The authors compared Ginger with seven libraries: ParlayANN, SVS, DiskANN, Hnswlib, SymphonyQG, Faiss and ScaNN. They used 14 public datasets: six low-dimensional sets of 96 to 200 dimensions, five of them with a billion vectors, and eight high-dimensional sets of 768 to 4096 dimensions with up to about 101 million vectors. Everything ran on one Google Cloud c4-highmem-288 machine with two 72-core Xeon processors and 2.3 TB of RAM. Queries were processed individually in parallel without batching, with one discarded warm-up and five timed runs per configuration, while parameter sweeps traced throughput against recall. Separate ablation studies isolated individual components. We should weigh two facts: the developers ran this comparison themselves on very large hardware, and they patched SVS and ScaNN to speed up builds so those libraries could be included. The benchmark harness is promised but described as not yet released.

6. How it performed

The copy we reviewed lost the headline speedup multiples and was cut off during the ablation results, so we quote only what survived. Ginger led throughput on 13 of 14 datasets; on BigANN, SVS was faster. With PiPNN it built fastest on 11 of 14, taking 34m30s on billion-vector Deep against 57m51s for Faiss and 9h31m for SVS. It had the smallest graph index on the four low-dimensional datasets charted for memory, though IVF libraries were competitive there. On high-dimensional data, SVS used less memory than 12-bit Ginger in the geometric mean but ran slower with lower peak recall, while 8-bit Ginger undercut SVS on memory. PCA and the prefilters do not stack well, and the index lives in RAM. The portion we read does not assess filtered search or live updates. Our call: pilot Ginger on our own embeddings and recall targets before planning any migration. (Source: arXiv 2611.08306, 2026)