Vector Store Integrations
Purpose and Scope
Vector store integrations are the persistence and search adapters that let a LlamaIndex application store embeddings outside the in-memory application process. In the broader indexing flow, a vector index turns document or node text into embedding vectors, then retrieves semantically related nodes for a query. This page explains the shared contract that integrations are expected to fit, then uses the MongoDB and Redis integration snippets as concrete examples of how provider packages translate that contract into backend-specific index definitions, field names, metadata filters, and operational setup. Sources: docs/api_reference/api_reference/storage/vector_store/index.md, llama-index-core/llama_index/core/vector_stores/types.py
The public API reference for vector stores is intentionally anchored on the core type module rather than on a single database implementation. That design matters because the repository separates the framework package from many independently installable integration packages. Application code should reason in terms of query results, query modes, filters, node identifiers, document identifiers, text, and vectors, while each backend package handles the details of schema creation, index naming, search index readiness, or storage-specific field definitions. The integration layer is therefore a portability boundary, not merely a collection of drivers. Sources: llama-index-core/llama_index/core/vector_stores/types.py, llama-index-integrations/vector_stores/llama-index-vector-stores-mongodb/llama_index/vector_stores/mongodb/index.py, llama-index-integrations/vector_stores/llama-index-vector-stores-redis/llama_index/vector_stores/redis/schema.py
Relevant Source Files
- docs/api_reference/api_reference/storage/vector_store/index.md — The generated API reference entry points at the core vector store type module, making that module the authoritative public reference surface for this page.
- llama-index-core/llama_index/core/vector_stores/types.py — Defines shared vector store concepts such as query results, query modes, filter operators, filter conditions, strict metadata filters, default persistence names, and the legacy node-with-embedding alias.
- llama-index-integrations/vector_stores/llama-index-vector-stores-mongodb/llama_index/vector_stores/mongodb/index.py — Shows a provider-specific utility layer for MongoDB Atlas vector search index definitions, creation, deletion, readiness waiting, and filter field registration.
- llama-index-integrations/vector_stores/llama-index-vector-stores-redis/llama_index/vector_stores/redis/schema.py — Defines the default Redis vector store schema, including required LlamaIndex field names, Redis index metadata, storage type, and vector field defaults.
System-to-Code Mapping
The central source-to-code relationship is simple: the API reference exposes llama_index.core.vector_stores.types, and integration packages conform to the concepts described there. The core module defines a VectorStoreQueryResult with optional nodes, similarities, and ids. That shape lets a backend return full nodes when it can, scores when it computes them, and identifiers when retrieval or follow-up lookup should be delegated elsewhere. The same module names query modes such as default, sparse, hybrid, text search, semantic hybrid, learner-based modes, and maximum marginal relevance, giving integrations a vocabulary for different retrieval strategies. Sources: docs/api_reference/api_reference/storage/vector_store/index.md, llama-index-core/llama_index/core/vector_stores/types.py
Filtering is another important part of the shared contract. MetadataFilter accepts a key, an optional strict value, and a filter operator. The operators cover equality, comparison, inclusion and exclusion, array containment, full text matching, case-insensitive text matching, and emptiness checks. MetadataFilters then combines individual filters with logical conditions such as and, or, and not. The strict value types are significant because integers, floats, and strings should not be silently collapsed into the same representation before a provider adapter receives them. That protects applications that rely on numeric ranges, exact string matching, or array semantics. Sources: llama-index-core/llama_index/core/vector_stores/types.py
| Area | Core or integration element | Reader takeaway |
|---|---|---|
| API reference | llama_index.core.vector_stores.types | Start here for portable concepts used by vector store adapters. |
| Query result | VectorStoreQueryResult | Retrieval may return nodes, similarity scores, ids, or a combination. |
| Query behavior | VectorStoreQueryMode | Backends can expose default, sparse, hybrid, text, semantic hybrid, MMR, or learner-style retrieval modes. |
| Filtering | MetadataFilter and MetadataFilters | Filters carry strict typed values and explicit operators, then combine with logical conditions. |
| MongoDB setup | create_vector_search_index and drop_vector_search_index | Provider utilities create and remove Atlas vector search indexes around backend-specific definitions. |
| Redis schema | RedisVectorStoreSchema | Provider schema fixes default field names and vector search attributes for Redis. |
Integration Examples
The MongoDB integration demonstrates that vector store support often includes administrative helpers in addition to query-time behavior. Its private definition helper builds a fields array containing a vector field with dimensions, path, similarity, and type. When filter paths are supplied, it appends filter fields so those paths can participate in vector search filtering. The public create utility wraps that definition in a SearchIndexModel named by the caller and typed as vectorSearch. It can also wait until a predicate reports that the search index is ready, which is useful when provisioning indexes during deployment or test setup. Sources: llama-index-integrations/vector_stores/llama-index-vector-stores-mongodb/llama_index/vector_stores/mongodb/index.py
The MongoDB drop utility shows an operational edge case that integration authors must handle carefully. Dropping an index is not always an instant local operation; the helper can wait until completion, and it treats an operation failure containing an already requested deletion message as a non-fatal condition. That behavior makes repeated cleanup safer when deployment automation or tests retry the same teardown step. The important pattern for readers is that provider packages may expose backend lifecycle tools alongside the shared vector store interface, because some databases require explicit server-side index management before queries are reliable. Sources: llama-index-integrations/vector_stores/llama-index-vector-stores-mongodb/llama_index/vector_stores/mongodb/index.py
The Redis integration snippet is schema-centered rather than lifecycle-centered. It declares required LlamaIndex field names for node id, document id, text, node content, and vector data. Its default index information uses the name llama_index, the prefix llama_index/vector, an underscore key separator, and hash storage. The schema constructor then defines tag fields for node and document identifiers, a weighted text field, and a vector field with dimensions set to 1536, a flat algorithm, and cosine distance. Those defaults show how a backend maps LlamaIndex concepts onto a concrete search schema. Sources: llama-index-integrations/vector_stores/llama-index-vector-stores-redis/llama_index/vector_stores/redis/schema.py
Compact Reference
Use the core vector store types when writing code that should remain portable across databases, and use provider utilities only where backend-specific setup is necessary. A portable retrieval layer should treat returned nodes, scores, and ids as optional because the result container permits each field to be absent. A filtering layer should build explicit metadata filters instead of passing untyped dictionaries throughout the application. A deployment layer, however, may need provider-specific configuration such as MongoDB vector dimensions and similarity names or Redis vector dimensions, distance metrics, index names, prefixes, and storage type. Sources: llama-index-core/llama_index/core/vector_stores/types.py, llama-index-integrations/vector_stores/llama-index-vector-stores-mongodb/llama_index/vector_stores/mongodb/index.py, llama-index-integrations/vector_stores/llama-index-vector-stores-redis/llama_index/vector_stores/redis/schema.py
- Query result container: VectorStoreQueryResult with optional nodes, similarities, and ids.
- Query modes: default, sparse, hybrid, text_search, semantic_hybrid, svm, logistic_regression, linear_regression, and mmr.
- Filter operators: equality, inequality, numeric comparison, inclusion, exclusion, array matching, text matching, case-insensitive text matching, contains, and empty checks.
- Filter conditions: and, or, and not.
- Default persistence constants: ./storage and vector_store.json.
- Redis required fields: id, doc_id, text, _node_content, and vector.
- Redis default vector attributes: dims 1536, flat algorithm, and cosine distance.
- MongoDB setup inputs: collection, index name, embedding dimensions, vector path, similarity, optional filter paths, optional wait timeout, and additional SearchIndexModel options.
Implementation Guidance and Next Steps
When selecting a vector store integration, begin with the retrieval behavior your application needs rather than with the database name alone. If the application needs pure semantic retrieval, the default query mode and a straightforward vector field may be enough. If it needs keyword constraints, metadata governance, or blended retrieval, verify that the chosen backend supports the relevant filter operators and query modes in practice. Then align embedding dimensions with the schema or index definition. A mismatch between the embedding model and the configured vector field is a common deployment-time failure point in vector search systems.
For source work inside this repository, treat the core type module as the shared contract and the integration package as the backend adapter. Changes to filter semantics, result shape, or query mode naming should be considered framework-level compatibility changes because many integration packages can depend on those names. Changes to MongoDB index creation or Redis schema defaults are narrower, but they still affect user deployments that rely on default field names, prefixes, storage formats, or readiness behavior. Related pages to read next are Vector Store Indexing for indexing flow, Retrievers for query-time behavior, Persistence for storage architecture, and Storage API for adjacent store contracts.