Turbovec brings Google's TurboQuant vector compression to Rust, with 15.5k GitHub stars

I would like LanceDB and DuckDB integrations. Those would make it much easier to add this to an existing data stack.

I need a README written for people, not something that reads like generated documentation, before I would adopt a project like this.

The reported 4 GB for 10 million documents is compelling. It could make reverse-index builds, debugging, and performance tests much less painful, and I am waiting for SQLite bindings.

I would use this for indexing a codebase, documentation, notes, or a personal wiki in an agent workflow.

I want local, privacy-first search in a browser extension. Has anyone compiled the Rust code to WASM, and can WASM access AVX512-VNNI?

I have used similar vector compression for job search and got about 8x compression with roughly a 3.5% quality loss. That is the comparison I would want to make here.

I do not see why I would use this instead of Qdrant. Qdrant has integrated TurboQuant for months, expanded Turbo4 data types in its latest release, and can avoid storing fp32 vectors.

FAISS is no longer close to state of the art on ANN benchmarks. TurboQuant's claim is more about the size and accuracy tradeoff than absolute search speed.

I am concerned by the OpenReview comments on TurboQuant. They say a reportedly better alternative, RaBitQ, already has implementations in many places.

I am not convinced Turbovec retrieves better than a Matryoshka embedding given the same bit budget.

Fine-tuning embedding models cut our vector costs substantially. We reduced frontier embeddings from 1,000 to 2,000 dimensions down to 64, and I want to know whether TurboQuant replaces that approach or combines with it.

I would read the allegations of academic misconduct around TurboQuant before treating this as an uncomplicated technical win. Some commenters and write-ups say the overlap with RaBitQ was deliberate.