PageIndex: RAG without a vector database

TL;DR: PageIndex is a Python project for retrieval-augmented generation that skips the vector database entirely. Instead of embedding chunks and searching by similarity, it builds a document tree and lets a model reason over the structure. MIT licensed, 37,428 stars, and the largest repository in today’s trending batch by a wide margin.

The pitch

The repository description names the whole idea: “Document Index for Vectorless, Reasoning-based RAG.” Two claims in eight words, and both of them push against the default architecture.

Vectorless means no embedding step. If you have shipped a RAG system, you know what that removes: the chunking decisions, the embedding model choice, the vector index, the tuning of similarity thresholds, and the recurring failure where a semantically perfect chunk sits three documents away from the answer. None of it exists if you never embed.

Reasoning-based means the retrieval decision happens inside a model that can look at a document’s structure and decide where to look. That is a real capability, and it is also the expensive part. You are trading an approximate nearest-neighbour lookup for deliberate inference.

The topics give the positioning away: agentic-ai, agents, ai, ai-agents, context-engineering. Context engineering is the phrase worth sitting with, because it names a category that did not have a name two years ago.

Why the default approach gets abandoned

Vector search works well until the corpus gets structured. Flat chunking treats a contract the same as a blog post, and then the retrieval returns a paragraph with the wrong section heading above it. A clause about termination sitting in a chunk whose neighbours are all about payment schedules is technically relevant and practically useless.

A document tree gives the model the shape of the original. Headings, sections, and nesting are all structural information that survives indexing, and a model that can see that structure can reason about which part of a document a question belongs to before it reads a word of it.

The cost lands somewhere specific. You are paying inference for retrieval on every query, and you are paying it on a structure that has to be built correctly up front. Both costs are real, and neither one is hidden by the project’s framing.

	Vector RAG	Reasoning-based
Indexing	Embed every chunk	Build a document tree
Retrieval	Similarity search	Model reasons over structure
Infrastructure	Vector database required	No vector store
Query cost	Low, one embedding	Higher, inference per query
Fails when	Chunking splits meaning apart	Tree is shallow or flat

The scale

PageIndex is the largest project in this batch by a distance. 37,428 stars and 3,264 forks, in a repository created in April 2025. The fork ratio sits just under 9 percent, which for a library rather than a service is a good sign. People fork libraries when they intend to read them or depend on them directly, not when they are browsing.

MIT is the other notable detail. For a component that is meant to sit inside someone else’s retrieval pipeline, permissive licensing means it can go into commercial code without friction, and that is often the only reason a team evaluates a library at all.

Written in Python, which means it drops into an existing data stack without new infrastructure, and which is also the language most RAG prototypes are written in. The last push was the day before this was written.

When to try it

The honest test is whether your queries fail against vector search for structural reasons. If people ask “what are the termination conditions” about a document with a termination section, and your current system returns payment schedule text, you are in the case this is built for.

If your corpus is a pile of short, flat, unstructured documents, there is no tree to build and the advantage largely disappears. Structure is the input that makes reasoning-based retrieval work.

It is also worth checking the latency profile against your own traffic before committing. A retrieval step that reasons has a different cost curve than one that embeds, and that difference is the entire tradeoff you are making.

When it is not the right tool

High-volume query traffic with tight latency budgets is the case where the cost curve bites hardest. If you are serving thousands of queries a second and your current retrieval works acceptably, the operational risk of moving is harder to justify than the architectural elegance is worth.

It is also not a drop-in replacement for a tuned vector pipeline you already monitor and maintain. You would be swapping a system whose failure modes you understand for one whose you do not.

Source and Accuracy Notes

• Project page: https://github.com/VectifyAI/PageIndex
• Source repository: VectifyAI/PageIndex (verified via GitHub API html_url)
• License: MIT (verified via GitHub API license.spdx_id)
• Stars at time of writing: 37,428
• Project site: https://pageindex.ai
• The vectorless and reasoning-based design, along with the document tree structure, is taken from the repository description as published by the maintainers. Benchmarks, supported formats, and model requirements were not independently verified.