REDIS REDISEARCH · TECH
Redis with RediSearch: vector index in the KV store for low latency
Redis with the RediSearch module ships an HNSW vector index since version 2.4. Useful when Redis already runs in the stack; fewer vector features than specialised DBs.
Researched & fact-checked by: DuneDive LLC · As of: 2026-05
What is Redis with RediSearch?
Redis is an in-memory key-value store, established since 2009 as a standard tool for caching, session storage, rate limiting, and pub/sub. RediSearch is an optional module by Redis Ltd. (formerly Redis Labs) that adds full-text search, geospatial indexing, and – since version 2.4 (2022) – vector search via HNSW or FLAT. As of May 2026, RediSearch 2.8 is current, with improved HNSW performance and multi-vector support per hash/JSON entry.
Licensing has differed by variant since 2024. Redis Open Source up to version 7.2 ran under BSD; from version 7.4, Redis OS sits under the dual RSALv2/SSPL license – a source-available but no longer OSI-conformant license that restricts cloud-vendor use. Self-hosting inside a law firm or fiduciary office is unaffected; SaaS repackaging of Redis is. The open fork Valkey (Linux Foundation, since 2024) is an alternative; RediSearch, however, runs primarily on Redis OS.
The architecture is in-memory with optional persistence (RDB snapshots, AOF append-only file). A Redis instance typically has several GB of RAM; vector search adds the vector index as an extra RAM consumer. Sharding via Redis Cluster is possible; RediSearch indexes distribute across shards.
The cloud offering Redis Cloud has EU regions (Ireland, Frankfurt) and SOC2 compliance. Self-hosted runs on any platform – Hetzner, AWS, own servers.
In the Swiss fiduciary context, Redis with RediSearch fits a clear profile: complementary tool when Redis already runs as cache or session store. Vector search in the same Redis saves a separate service. Anyone starting without a Redis setup and needing only vector search is better off with Qdrant or Weaviate – the specialisation of dedicated vector DBs is an advantage here.
Why it matters
Swiss fiduciary and SME stacks often run Redis as cache or session store – Bexio plugins, workflow tools, custom web apps. When vector load is moderate (e.g. an internal knowledge base with 50,000 entries) and Redis already runs, RediSearch can avoid a second database. The argument parallels pgvector vs Qdrant: no second DB, no second backup, no second monitoring.
Three properties make Redis with RediSearch interesting for this profile. First: latency. In-memory search typically delivers under 5 ms, often under 1 ms. For real-time use cases – live recommendation, autocomplete with embedding hits, sub-10ms RAG lookup – Redis is faster than any other vector DB. Qdrant and Weaviate sit at 10-30 ms, pgvector at 20-50 ms, Pinecone at 30-80 ms (cloud roundtrip).
Second: hybrid with classical Redis features. A vector hit can be combined in the same pipeline with pub/sub messages, rate limits, counters, or set operations. For recommendation systems with real-time personalisation, these primitives already exist – no adapter between vector DB and cache needed.
Third: operational familiarity. Anyone running Redis for years knows backups, failover, RBAC, cluster mode. RediSearch inherits these tools. An extra learning curve for a specialised vector DB drops out.
Counter-arguments: RediSearch is younger as a module than core Redis features; some vector-specific features (e.g. multi-vector per entry with independent search configs, hybrid BM25+dense in one query) are less mature than in Qdrant or Weaviate. Anyone running vector search as primary purpose has the more mature platform there.
License question: SSPL/RSALv2 is no problem for internal fiduciary use. For SaaS products that resell Redis as a database component, a license review is needed.
How it works
Installation: RediSearch ships in Redis Stack – a distribution bundling Redis OS plus RediSearch, RedisJSON, RedisGraph, and other modules. Docker: docker run -p 6379:6379 redis/redis-stack-server. Self-hosting via APT/YUM with the Redis Stack packages.
Create index via FT.CREATE – the RediSearch command prefix: FT.CREATE docs_idx ON HASH PREFIX 1 doc: SCHEMA mandant TAG datum TEXT content TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 1536 DISTANCE_METRIC COSINE
This creates an index on all hashes with prefix doc:; the fields mandant, datum, content, and embedding are indexed, with embedding as HNSW vector index, dimension 1536, cosine distance.
Upsert via HSET: HSET doc:1 mandant 42 datum "2026-04-01" content "Invoice Müller" embedding <binary_blob>
Embedding is written as a binary blob in float32 format – typically via SDK (redis-py, ioredis, lettuce). The Python variant: import redis import numpy as np r = redis.Redis() emb = np.array([0.1, 0.2, ...], dtype=np.float32).tobytes() r.hset("doc:1", mapping={"mandant": "42", "datum": "2026-04-01", "content": "Invoice Müller", "embedding": emb})
Search via FT.SEARCH with the KNN operator: FT.SEARCH docs_idx "(@mandant:{42})=>[KNN 10 @embedding $query_vec AS score]" PARAMS 2 query_vec <binary_blob> RETURN 3 content datum score DIALECT 2
Filters (@mandant:{42}) run before the KNN step – RediSearch handles this in one pipeline. Results carry score and RETURN fields.
Multi-vector per entry (since 2.6): one hash can hold multiple vector fields (e.g. text_embedding and image_embedding) and be queried in combination. Practical for multi-modal use cases.
Persistence: RDB snapshots (BGSAVE) and AOF (append-only file) cover backup. Cluster mode distributes RediSearch indexes across shards; a search fans out across all shards.
Redis with RediSearch to production in 5 steps
- 01Install Redis Stack: Docker with redis/redis-stack-server image or APT package on a self-hosted server. Enable persistence (RDB + AOF).
- 02Plan the index schema: FT.CREATE with all filter fields (TAG, TEXT, NUMERIC) and the vector field as HNSW or FLAT. Dimension matching the embedding model.
- 03Set up the embedding pipeline: texts are vectorised externally (OpenAI, Cohere, sentence-transformers); HSET writes the vector as float32 binary plus filter fields.
- 04Search with filter and KNN: FT.SEARCH with (@filter)=>[KNN K @vec $param AS score] DIALECT 2. Optional score threshold to drop weak hits.
- 05Backup and monitoring: hourly RDB snapshots, persistent AOF; INFO command in Prometheus exporter; per-shard separately in cluster mode.
When to use Redis with RediSearch
Redis with RediSearch fits when (a) Redis already runs in the stack as cache or session store, (b) sub-10ms latency is required for vector search, (c) real-time personalisation is combined with concurrent counter and set operations, or (d) data volume is small enough for in-memory storage to remain economical (< 5M vectors at 1536 dim ~ 30 GB RAM).
Concrete cases: an e-commerce system with live recommendation – customer views product X, semantically similar products from the 50,000-item catalogue appear in under 5 ms. An autocomplete function with embedding hits: user types, semantic results appear without perceivable delay. A chatbot system with session memory in Redis and vector lookup in the same Redis instance for context bridging.
For multi-modal with text and image, RediSearchs multi-vector feature from version 2.6 fits – both embeddings in one hash, combined in one search. For fiduciary receipt recognition with OCR text and image embedding, this is a valid option provided the data volume stays within the RAM budget.
Redis Cloud (managed) offers EU regions in Frankfurt and Ireland; for DACH customers with moderate load (< 10 GB RAM, < 1000 QPS), the cloud variant from USD 50/month is an option. Self-hosted on Hetzner from CHF 30/month for a 16 GB RAM server.
The profile is therefore not "Redis instead of Qdrant for everything", but "Redis for the subset where low latency and stack integration matter more than vector DB depth".
When not to use
If Redis is not already in the stack, introducing it solely for vector search rarely pays off. A specialised vector DB like Qdrant is simpler to run – no cluster mode, no RDB/AOF tuning, more focused API.
At data volumes over 10M vectors, Redis as in-memory solution becomes expensive. 10M vectors at 1536 dim need about 60 GB RAM for the HNSW index plus payload. A 128 GB RAM server costs much more than a comparable setup with Qdrant disk options or Milvus with DiskANN. At 100M vectors, Redis is no longer economically defensible.
For complex hybrid search (BM25 plus dense in one query with score mix), RediSearch is less mature than Weaviate or Elasticsearch kNN. Full-text search exists, but the BM25-score combination with vector distance is more manual.
When license sensitivity is high (e.g. for SaaS products reselling Redis), RSALv2/SSPL is a problem. Valkey as open-source fork solves the license question, but RediSearch module compatibility is not guaranteed – Valkey equivalents exist partially but are less mature as of May 2026.
For use cases requiring strict ACID consistency with relational data, Redis (eventual consistency in cluster mode) is not a good choice. pgvector is clearly superior there.
For long-term persistence (archival RAG over 30 years of documents), Redis is not the right tool – in-memory plus snapshots is more expensive and less safe here than disk-based systems.
Trade-offs
STRENGTHS
- Sub-10ms latency for vector search via in-memory architecture
- No second DB when Redis is already in the stack
- Hybrid with pub/sub, counter, set operations in one pipeline
- Multi-vector per entry for multi-modal use cases from v2.6
WEAKNESSES
- In-memory becomes expensive past 10M vectors – RAM cost scales linearly
- RSALv2/SSPL license forbids SaaS repackaging of Redis
- Hybrid BM25+dense search less mature than Weaviate/Elasticsearch
- Restricted vector-specific feature set vs specialised DBs
FAQ
How much RAM does Redis with RediSearch need for 1M vectors?
Rule of thumb: 4 bytes per vector dimension per entry for float32 HNSW. 1M vectors at 1536 dim yield about 6 GB just for vectors plus 30-50% HNSW overhead plus payload RAM. Realistically 10-12 GB RAM for one million entries. With 384-dim embeddings (MiniLM), a quarter of that. FLAT index uses less RAM but is slower.
What is the difference between HNSW and FLAT in RediSearch?
FLAT is brute-force search without index – each query computes distance to all vectors. Accurate but slow past 100,000 entries. HNSW is the standard ANN index, sub-linear in search, with configurable m and ef_construction. For production setups past 10,000 vectors, HNSW is mandatory.
What does the Redis license change mean for self-hosting?
Internal self-host use – inside the customers fiduciary, law firm, or own platform – is unproblematic under RSALv2/SSPL. Forbidden is reselling Redis as a managed cloud service under your own brand. For that case: Valkey (Linux Foundation, BSD-3) is the open-source alternative. RediSearch module compatibility with Valkey is not yet complete as of May 2026.