RediSearch

Last reviewed Sep 13, 2026 · 854 words

Only add RediSearch to your stack if Redis is already in it. Under that condition it is the cheapest search engine you will ever deploy: one module, one FT.CREATE, and the data you already cache becomes queryable with typo tolerance, filters, aggregations and vector similarity, all served from memory in sub-millisecond time. Under any other condition, Meilisearch or Typesense will get you to a working search box faster, with a friendlier licence and a fraction of the RAM.

The licence is the first thing to read, not the last

RediSearch is RSALv2, source-available rather than OSI open source, and the practical meaning is narrow but real: you may run it, modify it, and ship products on it, but you may not offer it to third parties as a managed service. For a homelab or an internal app this changes nothing. For anyone building a hosted product where search is the product, it matters, and it is the reason the module has 6,230 stars rather than the 60,000-plus of the engine it bolts onto. Redis 8 reshuffled the licensing again and folded the query engine into the main distribution, so check the exact terms attached to the image tag you pull. The licence primer for self-hosters covers what "source-available" does and does not restrict.

Getting it running is one image swap

The module is not something you compile against a stock Redis. You run a distribution that bundles it:

services:
  redis:
    image: redis/redis-stack-server:latest
    ports:
      - "6379:6379"
    volumes:
      - ./redis-data:/data
    restart: unless-stopped

That image is a drop-in for a plain redis container: same port, same RESP protocol, same clients, plus the FT.* command family. Existing keys are untouched. Create an index over hashes with a prefix and searching starts immediately:

FT.CREATE idx:articles ON HASH PREFIX 1 article: SCHEMA title TEXT WEIGHT 2 body TEXT tags TAG published NUMERIC SORTABLE
FT.SEARCH idx:articles "@title:(docker compose) @tags:{homelab}" SORTBY published DESC LIMIT 0 10

Indexes are maintained live as hashes change, which is the feature that makes it feel different from every other search engine: there is no sync job, no indexing queue, and nothing to fall behind.

Vector search is real but count the bytes

The same index can hold embeddings, and this is why RediSearch shows up in RAG conversations alongside Qdrant:

FT.CREATE idx:docs ON HASH PREFIX 1 doc: SCHEMA text TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

A 768-dimension float32 vector is 3,072 bytes before the HNSW graph overhead, so 1 million documents is roughly 3 GB of RAM for vectors alone, plus the text index, plus the source hashes. Everything lives in memory; the 512 MB minimum in the catalogue is a floor for trying it, not for holding a corpus. If your vector count is heading past a few million, a purpose-built store that pages to disk is the safer bet, and the vector database guide lays out that threshold. Under that size, having embeddings, metadata and cache in one process you already operate is a genuine simplification.

Where it loses to the dedicated engines

Three places. Ranking control: Meilisearch and Typesense expose ranking rules as a sorted list you can reason about; RediSearch gives you TF-IDF or BM25 with field weights and expects you to tune queries. Operational tooling: there is no dashboard, no built-in UI for testing queries, and no admin API beyond FT.INFO. Persistence semantics: RDB snapshots and AOF are Redis's answer, and a restart on a large index means rebuilding it in memory, which on a 20 GB dataset is minutes, not seconds. The Elasticsearch vs Meilisearch comparison is a fair map of the dedicated options; RediSearch sits off to the side of that chart, chosen for what it shares infrastructure with rather than for search features.

Who actually runs it

Teams with an app that already keeps its hot data in Redis and wants to filter and rank that data without a second datastore. Session stores that need "find users where plan = pro and last_seen > X" without a round trip to Postgres. Small RAG pipelines where the embeddings count fits in a few GB and the developer would rather learn zero new systems. It is not a good fit for indexing a document archive, a wiki, or a media library, because those datasets are large, cold, and rarely in Redis to begin with.

What I'd do

If Redis is in your compose file, switch the image to redis-stack-server, add one FT.CREATE, and see whether it solves the search problem before installing anything else; for most in-app search under a few million records it will. If Redis is not already there, do not introduce it for search. Run Meilisearch, which is MIT, ships a UI, and holds an index on disk rather than in RAM. The search category has the full field if neither shape fits.