[Feature Request]: Add Valkey Vector Store support

[daric93]

Feature Description

Add a new vector store integration for Valkey, an open-source key-value datastore that supports high-performance vector similarity search through the valkey-search module. This integration would use the official valkey-glide Python client to provide LlamaIndex users with a production-ready, AWS-supported alternative to Redis for vector search workloads.

Reason

Valkey is gaining significant traction as an open-source alternative to Redis. Several factors make this integration timely and valuable:

1. Open Source Governance: As a Linux Foundation project, Valkey offers transparent governance and community-driven development
2. Redis Compatibility: Valkey maintains protocol compatibility for core features with Redis while adding new features, making migration straightforward
3. Performance: The valkey-search module delivers single-digit millisecond latency with 99%+ recall for vector search operations
4. Growing Adoption: Major cloud providers are offering managed Valkey services with vector search capabilities

Value of Feature

• Seamless integration with Valkey's high-performance vector search using the official valkey-glide client
• Support for both exact (FLAT) and approximate (HNSW) algorithms with hybrid search combining vector similarity and metadata filtering
• Linear scaling with cluster mode support, open-source licensing, and managed service options from major cloud providers
• Provides an open-source alternative with clear governance, commercial support options, and easy migration paths from Redis deployments

[daric93]

I'd like to implement this integration if it aligns with the LlamaIndex roadmap and maintainers are interested.

[MkDev11]

@AstraBert Sorry to bother you. I’d like to implement this and would appreciate a quick sanity-check on the approach before opening a PR.

Proposed approach

• Add a new integration package (e.g. llama-index-vector-stores-valkey) that depends on the official valkey-glide Python client.
• Implement a ValkeyVectorStore that follows the same pattern as the existing Redis vector store: schema-driven index (FT.CREATE), add/query/delete, metadata filters, and sync + async APIs, but using valkey-glide and Valkey-Search’s FT.* commands instead of redisvl.
• Reuse the same conceptual schema (e.g. id, doc_id, text, vector + optional metadata) and support FLAT and HNSW as in the issue.

Question
Is maintaining a dedicated Valkey integration (valkey-glide-based) the desired direction, or would the maintainers prefer to document using the existing Redis vector store against a Valkey + valkey-search endpoint and avoid a separate package?

I am willing to adjust the plan based on your preference.

[daric93]

@MkDev11 Thanks for your interest in this! I actually started working on this integration already (as mentioned in my earlier comment) and have made good progress on the implementation. I'm planning to open a PR soon.

I'm following the approach of a dedicated llama-index-vector-stores-valkey package using valkey-glide, with similar patterns to the Redis vector store. I believe maintaining a separate package makes sense since Valkey is positioning itself as a distinct project with its own roadmap.

[AstraBert]

Hey both, if @daric93 already started working on this I think it's best if they keep going and create a pull request to solve the issue.
It makes sense to maintain a separate package from Redis, but i would still try to take the Redis implementation as an example.
As a note for both, if this is the first time(s) contributing to LlamaIndex, try to limit using coding agents so that you can get familiar with the codebase (once you're familiar, you can more easily guide coding agents)

[MkDev11]

@AstraBert I already made it, can I open a PR?

[daric93]

@MkDev11 I'm actively working on it and will have a PR ready soon. If you've also implemented it independently, perhaps we can coordinate after my initial PR is merged - there's always room for improvements and additional features.

[daric93]

Hi @AstraBert, wanted to get your input before finalizing the PR.

My current implementation uses TEXT fields for metadata filtering to match Redis's behavior exactly. This gives us full feature parity and makes migration from Redis seamless. However, TEXT field support in Valkey-Search is currently in RC (Release Candidate) - it's stable and working, but not officially GA yet. The Valkey team estimates GA release around March 2025, though that could shift.

There are two paths forward:

Option 1: Wait for the new version release in March before merging the PR. The TEXT-based version feels more complete and gives users what they'd expect coming from Redis.

Option 2: Swap TEXT fields in the schema for TAG fields. This will limit filtering compared to Redis, but core vector search still works perfectly. I'll add TEXT support later when it's officially released.

What's your philosophy on this? Happy to go either direction - just want to align with you on the approach.

[AstraBert]

Hey! I'm not super opinionated on this, but I feel like it would be nice to have some kind of interoperability layer between Redis and ValKey to ease migration (so going with the TEXT option might be better).
Since the timeline is March 2025, I'd say that we can wait to merge the PR until the feature is GA, but also happy to merge TAG first and migrate to TEXT later (based on your preference and availability)

[daric93]

Thanks @AstraBert! Makes sense - I'll go with Option 1 and wait for TEXT support to reach GA. This gives us full Redis interoperability from day one without needing a follow-up PR.