When does PropertyGraphIndex beat VectorStoreIndex?

LlamaIndex offers two main index types for retrieval. `VectorStoreIndex` chunks documents, embeds the chunks, and retrieves nearest neighbors at query time. `PropertyGraphIndex` does something more: it uses an LLM to extract entities and relationships from each chunk and builds a knowledge graph. At query time, it can either retrieve relevant subgraphs, traverse paths between entities, or both. Graph wins where vector search structurally cannot. Two clear cases: 1. **Multi-hop questions.** 'Which products from suppliers based in countries that signed treaty X were recalled in 2023?' Vector search retrieves passages that mention each concept individually and hopes the LLM can stitch them together. Graph traversal walks supplier to country to treaty edges and returns the precise candidate set with the recalls cross-referenced. 2. **Entity-centric aggregation.** 'List all papers co-authored by people who worked at OpenAI before 2022.' Vector search returns semantically related text but no clean set. Graph traversal handles this naturally. It is a structured query against a graph. The cost is real. Ingest requires an LLM call per chunk for entity and relation extraction, typically 10-50x the cost of just embedding the chunk. The extractor's quality bounds the graph's quality. A noisy extractor on a noisy corpus produces a noisy graph. And you need a graph store (Neo4j, Kuzu, or LlamaIndex's in-memory implementation) plus query logic on top. Heuristic: stay with vector when the workload is 'find passages similar to this question'. Reach for graph when multi-hop traversals or entity-structured queries dominate.

The two index types answer different question shapes. `VectorStoreIndex` is fundamentally a similarity primitive. Embed and retrieve. `PropertyGraphIndex` is a structured primitive. Extract entities and relations during ingest, then query the resulting graph by traversal, by entity match, or by hybrid graph plus vector lookup. **Two patterns where graph wins.** Multi-hop reasoning is the headliner. 'Which products from suppliers in countries that signed treaty X were recalled in 2023?' is three hops: products → suppliers → countries → treaty. Vector retrieval pulls top-k passages that mention each concept individually and the LLM has to do the join. The recall is brittle and the LLM frequently hallucinates connections that the corpus does not support. Graph traversal walks the relations directly and returns precisely the products that satisfy the chain. The second pattern is entity-centric aggregation. 'List all papers co-authored by people who worked at OpenAI before 2022.' This is a structured query against entities and their relations. Vector search returns 'papers semantically about OpenAI' which is not the same set and includes papers that merely mention OpenAI without an authorship link. Graph traversal returns the exact set. **The cost.** Ingestion is much more expensive. Every chunk requires an LLM call to extract entities and typed relations. On a 100k-chunk corpus, that is 100k LLM calls instead of zero (embeddings only). At GPT-4o-mini prices that is single-digit dollars; at Opus 4.7 it is hundreds. The graph quality is also bounded by the extractor's information-extraction quality. Adversarial domains (legal text, technical papers with novel entity types) produce noisy graphs unless you customize the extraction schema. The operational surface is bigger too. You need a graph store (Neo4j, Kuzu, LlamaIndex's `SimplePropertyGraphStore`) in addition to the vector store, and the query layer is more code.