Introduction
A developer named Ryan Codrai has released turbovec, an open-source vector search index written in Rust with Python bindings. It is built on TurboQuant, a vector quantization algorithm from Google Research whose paper was accepted at ICLR 2026 — but the library itself is an independent implementation with no connection to Google. It is MIT licensed and installable with pip install turbovec or cargo add turbovec.
The pitch is memory. A corpus of 10 million documents that occupies 31 GB of RAM as float32 embeddings fits in about 4 GB in turbovec, and the author's benchmarks show it searching that compressed representation faster than FAISS, the most widely used library in this space.
What TurboQuant does
Most production vector indexes compress with product quantization (PQ), which learns a codebook from a sample of your data before it can store anything. TurboQuant, described in the paper by Amir Zandieh, Majid Daliri, Majid Hadian and Vahab Mirrokni, takes a different route: it randomly rotates each vector, which makes every coordinate follow roughly the same Beta distribution, then applies an optimal scalar quantizer per coordinate.
Because nothing is learned from the data, the method is data-oblivious — there is no training phase and no parameters to tune. Google's own write-up focuses on a different application of the same idea, compressing the KV cache during inference to around 3 bits per channel; turbovec applies it to retrieval instead.
What the benchmarks show
All numbers below are the author's, measured on 100,000 vectors with 1,000 queries at k=64, against FAISS IndexPQFastScan sized to the same bit rate:
- Search speed: about 3.4x faster at 4-bit on x86 (Sapphire Rapids) and 3.5x on ARM (Google Axion); 20% and 26% respectively at 2-bit. The gains come from hand-written SIMD kernels — AVX-512 VNNI on x86, NEON SDOT/SMMLA on ARM.
- Recall: on OpenAI embeddings at 1536 and 3072 dimensions, calibrated TurboQuant beats FAISS at R@1 in three of four configurations and both reach 1.0 by k=8. On GloVe at 200 dimensions — where the algorithm's high-dimensional assumption is weakest — FAISS keeps a slight edge at 2-bit beyond k≈8.
- Insertion and deletion: a single
add()takes 6.3-19.7 µs; removing by ID takes under 1.4 µs, against 0.19-1.02 seconds for the equivalent FAISS call, which repacks stored codes on every removal.
Three caveats are worth stating plainly. These are the project's own benchmarks and have not been independently reproduced. The 10 million document figure is a memory calculation, not a measured search benchmark. And every recall number above was measured on 100,000 vectors — how accuracy holds up on a corpus a hundred times larger is unmeasured by anyone, including the author, which matters because a fixed bit budget has to separate proportionally more near-neighbours as a corpus grows.
What it actually competes with
The FAISS baseline here is IndexPQFastScan, a flat index that scores every stored vector on every query. That is the right comparison for what turbovec is, but it is also the category where turbovec looks best. Turbovec documents no HNSW or IVF structure, so it scans exhaustively too — and a team storing 10 million vectors in FAISS would reach for IndexIVFPQ or an HNSW graph, which skip most of the corpus per query and win on asymptotics no SIMD kernel can recover. Being 3.4x faster than flat PQ is not the same as being faster than FAISS.
The honest frame is therefore narrower than the headline: turbovec replaces an in-memory flat index, not an approximate-nearest-neighbour service. That covers a real and common case — up to a few million vectors on one machine, where RAM is the binding cost, latency at that scale is acceptable, and exhaustive scan buys exact ranking over the compressed vectors instead of a graph's recall cliff. Past that point the comparison that matters is against IVF or HNSW, and it has not been run.
Practical details
Several of the design choices target the operational pain of running a vector database in a RAG stack. sync(path) writes only what changed since the last call, so checkpointing a large index costs milliseconds rather than a full rewrite. Search accepts an allowlist of IDs, which the SIMD kernel honours directly instead of over-fetching and filtering afterwards — the usual way to enforce per-tenant or per-user visibility. Deletion works on stable external IDs, so references do not shift underneath you.
For teams already using a framework, the project ships adapters for LangChain, LlamaIndex, Haystack and Agno that replace each one's built-in in-memory store behind the same interface.
Conclusion
Turbovec is a young single-developer project, and its performance claims rest entirely on benchmarks the author ran. But the underlying algorithm is peer-reviewed work from Google Research, the code is MIT licensed, and the design targets a real constraint: teams running semantic search locally, where RAM is the binding cost and a managed vector service is not an option. If the 4-bit numbers hold up on someone else's hardware, an eight-fold memory reduction with no training step is a meaningful change to what fits on a single machine.