PageIndex vs turbovec
Vectorless, reasoning-based RAG — builds a hierarchical tree index from long documents so an LLM retrieves by relevance instead of similarity. No chunking, no embeddings, no vector DB. — versus — Rust vector index with Python bindings built on Google's TurboQuant: no training step, online ingest, hand-written SIMD kernels — 10M x 1536 vectors in ~4 GB, with allowlist-filtered search.
Opposite bets on retrieval. PageIndex removes vectors entirely and has the model reason over a tree index; turbovec makes vectors cheap enough that keeping them is the easy call. Choose by whether your corpus rewards similarity or structure.
| PageIndex | turbovec | |
|---|---|---|
| Stars | 35k | 17k |
| Forks | 3.1k | 1.4k |
| Language | Python | Rust |
| License | MIT | MIT |
| Last activity | today | 10 days ago |
| Topics | rag | rag, local, storage |
| Curated connections | 7 | 5 |
PageIndex — the curator's take
Reach for it on long, structured professional documents (contracts, filings, manuals) where similarity search returns 'similar but irrelevant' passages and you need reasoning over document structure. Tradeoff is per-query LLM reasoning cost/latency versus a cheap vector lookup, and you still need clean parsed text upstream. If your corpus is huge, homogeneous and similarity is good enough, a vector DB (chroma, supavec) is cheaper.
turbovec — the curator's take
Use it when the vector index is a component, not a product: you already have Postgres or BM25 doing the filtering and just need dense rerank that fits in RAM and accepts writes without a rebuild. The data-oblivious quantizer is the real ergonomic win — no train step, no parameter tuning, no reindex as the corpus grows, which is exactly the FAISS ritual people hate. It is an index, not a database: no metadata, no replication, no server, no hybrid scoring, bring your own storage and ID mapping. And it is quantized, so measure recall on your own corpus before you trust it over exact search.