Feature Proposal: Add Valkey as a Vector Database Option (using Valkey GLIDE)

[MatthiasHowellYopp]

Summary

I'd like to propose adding Valkey as a supported vector database in llmware, using the official Valkey GLIDE client library.

Why Valkey?

• Open-source successor to Redis — After Redis changed its license in 2024, Valkey emerged as the BSD-3-Clause licensed continuation, backed by AWS, Google, Oracle, and the Linux Foundation. It has surpassed 100 million Docker pulls and attracted 225+ contributors.
• Vector search + hybrid queries — The valkey-search module (v1.2) provides FT.CREATE / FT.SEARCH commands with HNSW and FLAT indexing, supporting vector similarity, full-text search, tag matching, numeric range filters, and hybrid queries combining all of these in a single request.
• Server-side aggregations — Valkey Search 1.2 adds FT.AGGREGATE with GROUPBY, REDUCE, SORTBY, and computed fields, enabling analytics without round-tripping data to the application layer.
• Cloud-native — AWS ElastiCache for Valkey (9.0+) and Google Cloud Memorystore for Valkey both support vector search natively.

Why Valkey GLIDE as the Client?

• Official client — GLIDE is the official Valkey client library, maintained by the Valkey project itself.
• Performance — Written in Rust with Python bindings, designed for high throughput and low latency.
• Built-in search module support — GLIDE has first-class ft module commands (ft.create, ft.search, ft.dropindex) as part of its Python API — no raw command passthrough needed.
• Sync and async — Offers both GlideClient (sync, since v2.1) and an async client, giving flexibility for llmware's synchronous embedding workflow.
• Cluster-aware — Native support for both standalone and cluster deployments via GlideClient / GlideClusterClient.
• Package: pip install valkey-glide (current version 2.3.1, supports Python 3.9–3.13)

Implementation Approach

Based on my review of the existing codebase, adding Valkey would involve:

1. New class EmbeddingValkey in llmware/embeddings.py

Implementing the three required methods following the same pattern as EmbeddingMilvus, EmbeddingRedis, etc.:

• create_new_embedding(doc_ids=None, batch_size=500) — iterate text blocks, generate embeddings, store as hashes with binary vector blobs, indexed by FT.CREATE
• search_index(query_embedding_vector, sample_count=10) — KNN query via ft.search with *=>[KNN k @vector $query_vec] syntax
• delete_index() — drop the index via ft.dropindex and clean up text index flags

2. New ValkeyConfig in llmware/configs.py

Following the same pattern as RedisConfig, MilvusConfig, etc.:

class ValkeyConfig:

    """Configuration object for Valkey"""

    _conf = {
        "host": os.environ.get("USER_MANAGED_VALKEY_HOST", "localhost"),
        "port": os.environ.get("USER_MANAGED_VALKEY_PORT", 6379),
        "user_name": "",
        "pw": "",
        "use_tls": False,
        "cluster_mode": False
    }

    @classmethod
    def get_config(cls, name):
        if name in cls._conf:
            return cls._conf[name]
        raise ConfigKeyException(name)

    @classmethod
    def set_config(cls, name, value):
        cls._conf[name] = value

3. Register in VectorDBRegistry

"valkey": {"module": "llmware.embeddings", "class": "EmbeddingValkey"}

4. Dependency

valkey-glide — optional, lazy-imported following the existing pattern used by all other vector DB drivers (no hard requirement at install time).

Sketch of the Vector Search Flow (GLIDE Python)

from glide import GlideClient, ft
from glide_shared.config import GlideClientConfiguration, NodeAddress
from glide_shared.commands.ft import (
    FtCreateOptions, FtSearchOptions, VectorFieldHnsw, DataType, DistanceMetric
)
import numpy as np

# Connect
config = GlideClientConfiguration([NodeAddress("localhost", 6379)])
client = GlideClient.create(config)

# Create index
schema = [VectorFieldHnsw("embedding_vector", DistanceMetric.L2, dim=768)]
options = FtCreateOptions(DataType.HASH, prefixes=["emb_prefix:"])
ft.create(client, "my_index", schema, options)

# Store vectors as hash fields
vec_bytes = np.array(embedding).astype(np.float32).tobytes()
client.hset("emb_prefix:block_id", {"embedding_vector": vec_bytes, "block_mongo_id": "abc123"})

# Search (KNN)
query = "*=>[KNN 10 @embedding_vector $query_vec]"
query_vec = np.array(query_embedding).astype(np.float32).tobytes()
results = ft.search(client, "my_index", query, FtSearchOptions(params={"query_vec": query_vec}))

# Drop index
ft.dropindex(client, "my_index")

Key Differences from the Existing Redis Implementation

Aspect	EmbeddingRedis (redis-py)	Proposed EmbeddingValkey (GLIDE)
Client library	redis (Python)	valkey-glide (Rust + Python bindings)
Search API	redis.commands.search method chaining	Module-level functions: ft.create(), ft.search()
Cluster support	Manual	Native via GlideClusterClient
TLS	Manual config	Built-in client option
License	MIT (client) / SSPL (server)	BSD-3-Clause (client + server)

The API surface is different enough from redis-py that this would be a standalone class rather than a shared base with EmbeddingRedis.

Questions for Maintainers

1. Standalone class vs. shared base — Are you open to this being a fully independent EmbeddingValkey class? Given the API differences with GLIDE, sharing a base with EmbeddingRedis would add complexity without much benefit.

2. Sync client — The GLIDE client supports both sync and async modes. Should the implementation use the sync GlideClient to match the existing synchronous pattern in other embedding classes?

3. Cluster mode — Should cluster mode be configurable via ValkeyConfig from the start, or is standalone sufficient for an initial implementation?

4. Version requirements — This implementation targets Valkey Search ≥ 1.2.0 (which adds full-text, tag, numeric, and hybrid query support alongside vector similarity). This requires Valkey ≥ 9.1. For users on managed services, AWS ElastiCache 9.0+ for Valkey and the valkey/valkey-bundle Docker image include the search module. Is there any concern with this being a relatively recent minimum version, or is that acceptable given this is a new integration with no backward compatibility to maintain?

I'm Happy to Implement This

If the maintainers are open to this addition, I'm willing to submit a PR with the full implementation, following the fork-and-pull workflow documented in CONTRIBUTING.md.

---

References:

• Valkey Search documentation
• Valkey Search 1.2 announcement
• Valkey GLIDE Python — ft module API
• valkey-glide on PyPI
• valkey-search on GitHub

[doberst]

@MatthiasHowellYopp - apologies for the delay in actioning this. We have a large backlog that we are working through. Please give us a couple of days, and we will revert. Really appreciate your contribution and support of llmware!

[MatthiasHowellYopp]

@doberst No worries. Happy to help, life is complicated, waiting is part of it. I'll ping again later in the month just to see how things are going.