feature: Valkey vector store backend

[daric93]

Describe the feature

Add Valkey as a VectorStoreBackend in pkg/vectorstore/ using valkey-glide Go client with CustomCommand for ValkeySearch operations (FT.CREATE, FT.SEARCH, FT.AGGREGATE, FT.DROPINDEX). This extends Valkey support to the VectorStore interface, complementing the existing Valkey CacheBackend work (#1484). Native valkey-glide search commands are expected in the 2.4 release (Q2 2026); a follow-up story will migrate from CustomCommand to native API.

Primary layer

plugin

Why this layer?

The vector store system is implemented as a pluggable architecture where different backends (Memory, Milvus, Llama Stack) implement the VectorStoreBackend interface. Adding Valkey follows this same plugin pattern, integrating at the vector store backend layer without requiring changes to the core semantic router logic.

Why do you need this feature?

Organizations wanting Valkey as their unified data layer for vLLM semantic router currently can't use it for RAG vector storage, document management, or hybrid search — forcing a separate vector database (e.g., Milvus) alongside Valkey. This increases operational complexity. Completing Valkey's VectorStore integration enables a single-backend deployment for both caching and vector storage, reducing infrastructure overhead while maintaining BSD licensing compliance.

Additional context

• Related: feature: add a Valkey cache backend #1484 adds Valkey CacheBackend in pkg/cache/.
• Implementation follows existing backend patterns, primarily milvus_backend.go as reference.
• All FT.* commands issued via valkey-glide CustomCommand until native API lands in v2.4.

[daric93]

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

[Xunzhuo]

@daric93 can you tell the advantages of valley comparing with others?

[daric93]

Technical comparison:

vs Memory (in-process)

• Valkey is in-memory by default but supports configurable persistence (RDB + AOF) — survives restarts when enabled. Memory backend loses everything on process exit.
• Cluster mode for horizontal scaling — memory backend is single-process only
• Shared across multiple router instances — memory backend is process-local

vs Llama Stack

• No external API dependency — no reliance on a running Llama Stack service
• Trade-off: Llama Stack integrates with its own ecosystem and may be preferred when already deployed

vs Milvus

• Simpler deployment — Valkey runs as a single server process. Milvus Standalone requires three containers (Milvus + etcd + MinIO); Milvus Distributed adds coordinator services on top.
• Shared infrastructure — with memory disabled (default), a single Valkey instance serves cache + vector store + response store + router replay. Milvus is only needed if agentic memory is explicitly enabled.
• Trade-off: Milvus has advanced features — IVF/DiskANN indexing, hybrid sparse-dense search, built-in BM25 since v2.5, and collection-level TTL.

Why Valkey is a good addition:

• With memory disabled, a single Valkey instance can now serve every persistent component: semantic cache (PR feat: initial implementation of valkey cache backend #1540), vector store for RAG (this PR), response store, and router replay (the response store uses standard Redis commands, fully compatible with Valkey). Milvus is only needed if you explicitly enable the agentic memory feature. For teams that don't use memory, this eliminates the need for any additional infrastructure beyond Valkey.
• Lower barrier for RAG features — Teams that want vector-based RAG but don't need agentic memory can now get it without deploying Milvus. Single container, familiar ops.
• Right-sized for routing scale — Routing vector collections are typically thousands to low millions of vectors. Valkey's in-memory HNSW handles this with sub-ms latency without dedicated vector DB infrastructure. Valkey's persistence feature can be configured as needed.
• Open-source alignment — Linux Foundation, BSD-licensed. No license ambiguity.
• Additive — Doesn't deprecate any existing backend. Milvus remains available and is still the only option for agentic memory (a separate effort could add a ValkeyStore for memory in the future).