RyanCodrai/turbovec
A vector index built on TurboQuant, written in Rust with Python bindings
Build with Backblaze B2
SDKs, agent skills, IDE extensions, and reference pipelines from Backblaze Labs. All open source.
Loading star history...
Where it stands
Rank, growth pace and release cadence relative to everything GStars tracks.
The project lists 8 contributors on GitHub.
Peaked at #17 in the weekly ranking the week of Aug 16, its best in the past year.
Use Cases & Benefits
- Implements a high-performance vector index using TurboQuant quantization with Rust and Python bindings for efficient approximate nearest neighbor search.
- Offers extreme memory compression and faster search speeds than FAISS by combining data-oblivious quantization, SIMD acceleration, and online indexing without retraining.
- Use for building privacy-sensitive, air-gapped retrieval-augmented generation (RAG) systems requiring local vector search with minimal RAM usage.
- Use for integrating a drop-in replacement vector store in frameworks like LangChain, LlamaIndex, or Haystack to accelerate embedding-based document retrieval.
- Use for large-scale, dynamic vector databases needing fast online ingest, stable external IDs, and filtered search with candidate allowlists at query time.
Should you depend on it?
License terms, project hygiene and risks, from GitHub metadata and GStars' snapshots.
License
MIT
Permissive: commercial use, modification and redistribution are allowed with attribution.
Community files
- README: present
- Contributing guide: present
Watch-outs
- No GitHub releases; pin a commit or tag instead of a release.
General guidance from repository metadata, not legal advice. How we score
From the README
A 10 million document corpus takes 31 GB of RAM as float32. turbovec fits it in 4 GB - and searches it faster than FAISS.
turbovec is a Rust vector index with Python bindings, built on Google Research's TurboQuant algorithm — a data-oblivious quantizer with near-optimal distortion and no separate training phase.
Building RAG where privacy, memory, or latency matters? You're in the right place.
Restrict results to a candidate set produced by another system (SQL, BM25, ACL, time window, …):
Filtering happens inside the SIMD kernel at 32-vector block granularity: blocks with no allowed slots are short-circuited before any LUT lookup or scoring work, and individual non-allowed slots inside scored blocks are dropped at heap-insert. Selective allowlists (small fraction of the index allowed) therefore avoid most of the SIMD cost rather than paying it and discarding the result afterwards.
The output length is
min(k, len(allowed))— when the allowlist is smaller thankyou get exactlylen(allowed)results rather than padded fallbacks.See
docs/api.mdfor the full reference.
Daily snapshots
Stars gained per day, and how forks and open issues moved, from GStars' daily snapshots
+2,717 stars over 84 days across 18 snapshot days; best day +252 on Aug 20.
Forks
1.5K+164
Open issues
24-4
Compared with peers in LLM
Fastest-growing repositories GStars tracks in this cohort for the week of Nov 8, by 7-day star growth
| Repository | Stars | +7d | Health | Last release |
|---|---|---|---|---|
| NVIDIA/auto-ontology | 11.4K | +8.5K | 75 | — |
| thedotmack/claude-mem | 115.8K | +4.7K | 75 | today |
| DietrichGebert/ponytail | 188.4K | +4.4K | 75 | 12 days ago |
| affaan-m/ECC | 300.8K | +4.3K | 75 | 40 days ago |
| Graphify-Labs/graphify | 145.7K | +3.8K | 75 | today |
| RyanCodrai/turbovec | 17.5K | — | 15 | — |
| Category median | 145.7K | +4.4K | 75 | — |
Discover Repositories
Search across tracked repositories by name or description