Index Storage

Purpose and Scope

Storage in LlamaIndex is the set of persistence and lookup abstractions that keep indexed application state usable across ingestion, retrieval, chat, and agent workflows. In a retrieval-augmented generation application, the same source documents may be represented as parsed chunks, embedded vectors, graph relationships, index metadata, and conversational memory. This page explains how those storage responsibilities fit together so that developers can choose the right backend, understand what is persisted, and know which API reference families to inspect when moving from an in-memory prototype to a production system.

The most visible storage choice is often the vector store because VectorStoreIndex embeds document chunks and uses vector similarity to retrieve relevant context. LlamaIndex also separates adjacent concerns: document stores hold source or chunk records, index stores preserve index metadata, key-value stores can back lightweight persistence, graph stores preserve relationship-oriented structures, and chat or memory stores support stateful conversations. Treat these as cooperating layers rather than one monolithic database; a production application may use one managed vector database, one graph store, and separate chat state depending on the workload.

Sources: docs/src/content/docs/framework/module_guides/storing/vector_stores.md, docs/api_reference/api_reference/indices/vector.md, docs/api_reference/api_reference/storage/graph_stores/index.md

Relevant Source Files

• docs/src/content/docs/framework/community/integrations/vector_stores.md explains the two integration roles for vector stores: using a vector store as an index backend and loading data from vector stores as connector-style inputs.
• docs/src/content/docs/framework/module_guides/storing/vector_stores.md describes vector stores as containers for embedding vectors of ingested chunks, documents the default simple in-memory vector store, and compares provider feature support.
• docs/api_reference/api_reference/indices/vector.md anchors the public VectorStoreIndex reference entrypoint.
• docs/api_reference/api_reference/memory/vector_memory.md anchors the vector-memory reference family used when conversational or agent memory is backed by vector retrieval.
• docs/api_reference/api_reference/retrievers/vector.md anchors VectorIndexRetriever and VectorIndexAutoRetriever, the retrieval-facing APIs that consume vector-backed storage.
• docs/api_reference/api_reference/storage/graph_stores/index.md anchors graph storage contracts including GraphStore, PropertyGraphStore, DEFAULT_PERSIST_DIR, and DEFAULT_PERSIST_FNAME.

System-to-Code Mapping

At the code and documentation level, vector storage sits between ingestion and retrieval. Documents or nodes are ingested, split, embedded, and written into a vector store. VectorStoreIndex is the index abstraction that makes those stored vectors queryable, while vector retrievers are the query-time entrypoints that select relevant nodes for downstream response synthesis. The module guide explicitly states that vector stores contain embedding vectors of ingested document chunks, and sometimes the chunks themselves, which is the central distinction to check before choosing a provider.

Sources: docs/src/content/docs/framework/module_guides/storing/vector_stores.md, docs/api_reference/api_reference/indices/vector.md, docs/api_reference/api_reference/retrievers/vector.md

The storage model also supports different persistence scopes. For quick experiments, the module guide describes a simple in-memory vector store that can be persisted to disk with vector_store.persist() and loaded with SimpleVectorStore.from_persist_path(...). That is useful for local notebooks, tests, and small demos where operational complexity should stay low. For applications that need metadata filtering, deletion, hybrid search, asynchronous operations, or managed durability, the same conceptual vector-store contract can be implemented by an integration package instead of the simple local store.

Sources: docs/src/content/docs/framework/module_guides/storing/vector_stores.md

Graph storage addresses a different retrieval shape. The graph store reference exposes GraphStore and PropertyGraphStore, along with default persistence constants, which signals that graph-backed RAG is modeled as a first-class storage family rather than as a special case of vector search. Use graph stores when relationships, entities, paths, or property-rich edges are part of the retrieval problem. A vector store answers “which chunks are semantically similar,” while a graph store can preserve explicit structure that is useful for traversals and relationship-aware retrieval.

Sources: docs/api_reference/api_reference/storage/graph_stores/index.md

Vector Store Backends and Feature Selection

The integration docs describe two ways vector stores participate in LlamaIndex. First, a vector store can act as the storage backend for VectorStoreIndex, storing embeddings and supporting similarity search for query-time retrieval. Second, a vector store can be used as a data source, similar to a connector, where data is loaded out of an existing vector database and then used inside LlamaIndex structures. This distinction matters during migrations: adopting a vector database as an index backend is different from importing existing vectorized content into a new ingestion pipeline.

Sources: docs/src/content/docs/framework/community/integrations/vector_stores.md, docs/src/content/docs/framework/module_guides/storing/vector_stores.md

Provider selection should be based on the behavior your application needs, not just whether a backend can store vectors. The storage guide compares more than twenty vector store options across type, metadata filtering, hybrid search, delete support, document storage, and async support. The community integrations page names many concrete backends, including Alibaba Cloud OpenSearch, Amazon Neptune Analytics, Cassandra and Astra DB, Azure AI Search, Azure Cosmos DB, Chroma, ClickHouse, Couchbase, DashVector, DeepLake, DocArray, Elasticsearch, FAISS, Google AlloyDB, Google Cloud SQL for PostgreSQL, Hnswlib, Jaguar, Lantern, MariaDB, Milvus, MongoDB Atlas, MyScale, and others.

Sources: docs/src/content/docs/framework/community/integrations/vector_stores.md, docs/src/content/docs/framework/module_guides/storing/vector_stores.md

A practical selection workflow starts with the query pattern. If users need semantic search over modest local data, the simple vector store may be enough. If filters such as tenant, timestamp, file type, or access-control metadata are required, choose a backend with metadata filtering. If lexical relevance and vector relevance must be combined, check hybrid search support. If documents must be updated or removed, delete support is mandatory. If your vector store does not store documents, keep a separate document store or source-of-truth record system so retrieved node identifiers can still be resolved into content.

Sources: docs/src/content/docs/framework/module_guides/storing/vector_stores.md

Runtime Consumers: Retrieval, Memory, and Chat State

Retrievers are the runtime consumers of vector-backed storage. The vector retriever reference exposes VectorIndexRetriever and VectorIndexAutoRetriever, which represent the query-facing layer on top of VectorStoreIndex. In application terms, the index owns the stored representation, while the retriever decides how a user query is converted into a storage lookup and which nodes are returned. Query engines, chat engines, and agents can then use those retrieved nodes as context for synthesis, tool use, or conversation turns.

Sources: docs/api_reference/api_reference/retrievers/vector.md, docs/api_reference/api_reference/indices/vector.md

Vector memory applies the same retrieval principle to stateful interaction. The vector_memory API reference indicates a memory family backed by vector retrieval, which is useful when prior conversation turns or remembered facts should be recalled semantically instead of only by recency. This complements chat stores: a chat store is responsible for preserving conversation messages, while vector memory is useful when the application needs to search across remembered content. In agent systems, this distinction helps keep transcript persistence separate from long-term semantic recall.

Sources: docs/api_reference/api_reference/memory/vector_memory.md

Index stores and key-value stores are supporting persistence layers around these higher-level features. The official API reference for index stores names KVIndexStore, reflecting a common pattern where index metadata can be persisted through a key-value abstraction. Developers should think of this as control-plane storage: it records how an index is organized and how persisted components can be reconstructed. Vector stores and graph stores usually hold queryable data-plane structures, while document stores, index stores, key-value stores, and chat stores keep the rest of the application state coherent.

Compact Reference

Storage family	Primary responsibility	Source-backed entrypoints or examples
Vector store	Store embedding vectors for ingested chunks, and sometimes chunk text, for semantic retrieval	VectorStoreIndex, VectorIndexRetriever, VectorIndexAutoRetriever, simple in-memory vector store, provider integrations
Graph store	Store graph or property-graph structures for relationship-aware RAG	GraphStore, PropertyGraphStore, DEFAULT_PERSIST_DIR, DEFAULT_PERSIST_FNAME
Vector memory	Recall conversational or agent memory through semantic lookup	llama_index.core.memory.vector_memory reference family
Index store	Persist index metadata and reconstruction state	Official API reference names KVIndexStore
Document or chat store	Preserve source chunks, documents, or conversation messages outside the vector lookup itself	Use alongside vector stores when the selected vector backend does not store documents or when stateful chat history must be retained

Execution Flow

A typical persistent RAG flow begins by loading documents and parsing them into nodes. The application builds a VectorStoreIndex, which embeds node text and writes vectors into the configured vector store. If using the simple local backend, the developer can persist it to disk and reload it later. If using an integration backend, the backend’s capabilities determine whether metadata filters, hybrid search, deletes, document storage, and async operations are available. At query time, a vector retriever reads from the stored vectors and returns candidate nodes for the query or chat engine.

Sources: docs/src/content/docs/framework/module_guides/storing/vector_stores.md, docs/api_reference/api_reference/indices/vector.md, docs/api_reference/api_reference/retrievers/vector.md

When graph retrieval is part of the design, add a graph store rather than forcing every relationship into vector metadata. The graph store API family gives a separate contract for graph persistence, which allows applications to combine semantic similarity with structured relationships. When memory is part of the design, decide whether the requirement is transcript persistence, semantic recall, or both. That decision determines whether a chat store, vector memory, or a combined strategy is appropriate. The clean separation of these storage concerns is what lets LlamaIndex applications evolve from demos into maintainable systems.

Sources: docs/api_reference/api_reference/storage/graph_stores/index.md, docs/api_reference/api_reference/memory/vector_memory.md

Next Steps

Start with the simple vector store while validating chunking, embeddings, and retrieval quality. Before production, review the vector store feature matrix and choose a backend with the filtering, deletion, hybrid search, async behavior, and document-storage guarantees your workload requires. Then inspect the VectorStoreIndex, vector retriever, vector memory, and graph store reference pages for the exact public classes used by your application. If you are designing a broader architecture, read the related pages on vector store indexing, retrievers, property graph RAG, persistence, chat engines, and sessions next.