RediSearch: the query and indexing engine that ships inside Redis 8

What RediSearch adds to a plain Redis instance

Redis on its own answers key lookups. It has no index over the contents of the values you store, so answering "which documents mention this word, published after this date, within this distance" means scanning keys yourself. RediSearch is the module that closes that gap. You declare an index over Redis data, then query that index through the RediSearch query language, as the README puts it: "To use RediSearch, you first declare indexes on your Redis data. You can then use the RediSearch query language to query that data."

The audience is narrow but common. If your application already keeps its working set in Redis and you need filtered retrieval, ranked text matching or nearest-neighbour lookups over the same data, adding a second system means a second copy of the data and a synchronisation path to maintain. RediSearch keeps the index next to the data. The README lists the feature set: full-text indexing over multiple fields in Redis hashes, numeric filters and ranges, geospatial search, geoshape indexing, auto-complete suggestions, phonetic matching, stemming in many languages, Chinese tokenisation through Friso, aggregations, and vector similarity search with KNN, filtered KNN and range queries. That is a wide surface for one module, and the breadth is the point: it is meant to be the retrieval layer for a Redis-resident dataset rather than a specialist tool for one query type.

Compressed inverted indexes and the incremental indexing promise

The core mechanism is stated plainly in the README: RediSearch "uses compressed, inverted indexes for fast indexing with a low memory footprint." An inverted index maps terms to the documents containing them, and the compression is what keeps that structure affordable in memory rather than on disk. Because Redis data is in RAM, index size is not an abstract concern; it competes with the documents themselves.

The second design claim is incremental indexing "without performance loss." New and updated documents are folded into the existing index rather than requiring a rebuild. That matters for a system that sits in front of live traffic. It also sets an expectation worth testing on your own data, because the phrase describes the intended behaviour rather than a measured guarantee, and the README does not publish a benchmark behind it.

Ranking defaults to BM25, with optional user-provided weights, and the README notes field weighting as a separate feature. Results can be returned as full documents, selected fields, or document IDs only, and can be sorted, for example by creation date. The query language supports AND, OR and NOT, prefix matching, fuzzy matching, exact-phrase queries, and double-metaphone phonetic matching. For vector workloads the same index serves KNN, filtered KNN and range queries, which means filtering and similarity ranking are expressed in one query rather than stitched together in application code.

Installing RediSearch in 2026: Redis 8 changed the answer

The most important installation fact is a note at the top of the README, not a command. Starting with Redis 8, Redis Query Engine, which is RediSearch, is integral to Redis, and the project states that you do not need to install the module separately. The same note says standalone versions of RediSearch are no longer released, and points readers to the redis/redis repository.

So the practical route is to run Redis 8 and confirm the Query Engine is present. The README does not document a version check command, so verify against your Redis build's own documentation rather than assuming. If you are pinned to an older server, the maintenance release badges in the README track three lines: 2.10, 2.8 and 2.6, with the most recent tags published on 2026-06-17. Those older lines are where a separately installed module still applies.

For building the module from source, the repository ships a Makefile that the file itself describes as "a thin wrapper around the build.sh script." The default target is build, and the Makefile exports the Cargo bin directory onto PATH, which tells you the Rust toolchain is expected to be available before you run it:

make build

Building in a container is also supported. The Dockerfile takes the base image as a build argument and shows the shape of the call in its own comments, for example ubuntu:24.04, rockylinux:9 or alpine:3:

docker build --build-arg BASE_IMAGE=ubuntu:24.04 .

One constraint is stated outright and is easy to miss: 32-bit systems are not supported. If you are targeting a 32-bit platform, stop here.

Declaring an index and querying it

RediSearch work starts with an index definition. The README points to the official getting-started tutorial and the command reference rather than embedding a full example, so the workflow is: declare an index over your Redis data, then query that index with the RediSearch query language. The README does not reproduce an FT.CREATE snippet, so check the command reference for the exact syntax of the fields and options in your version rather than copying one from here.

After the index exists, documents written to Redis are indexed incrementally. The README states that indexing is incremental, so there is no separate load step to schedule, and it describes indexing as happening without performance loss. Queries then run against the index through the query language, with AND, OR and NOT operators, prefix and fuzzy matching, and exact-phrase matching available.

Two details shape how you write the retrieval code. Ranking uses BM25 by default, with optional user-provided weights, so result order is meaningful out of the box. And results can be returned as full documents, selected fields, or document IDs only, which lets you avoid pulling large values across the connection when you plan to fetch them separately. The README does not document rollback of an index definition, so plan index changes as forward operations.

Where RediSearch is the wrong tool

The largest limitation is distribution. The README says RediSearch has a distributed cluster version that scales to billions of documents across hundreds of servers, and then says that distributed RediSearch is available as part of Redis Cloud and Redis Enterprise Software. The open source module does not give you that topology. If your requirement is a sharded search cluster you operate yourself, this is a commercial feature, and no amount of reading the repository changes that.

The second constraint is memory. A compressed inverted index is still an in-memory structure. RediSearch is a good fit when the corpus fits comfortably alongside the working set in RAM, and a poor fit when it does not. A system built around disk-resident indexes with tiered storage is a different category of tool, and choosing RediSearch for a corpus that outgrows memory means choosing a migration later.

The third is scope. RediSearch is a module inside Redis, not a standalone search platform. There is no separate query service, no cluster manager of its own in the open source build, and no separate upgrade cadence now that the code is integral to Redis. Teams that want to version search independently of their cache will find that the two are now the same release.

How RediSearch differs from Elasticsearch and OpenSearch

The honest comparison is about where the index lives, not about which query language is richer. Elasticsearch and OpenSearch are standalone search engines with their own processes, their own storage layer and their own cluster coordination. They are built to hold a corpus larger than memory and to shard across nodes out of the box. RediSearch assumes the opposite starting point: the documents are already in Redis, and the index is a structure over them.

That difference decides most adoption questions. If the application's source of truth is a search cluster and Redis is a cache in front of it, RediSearch adds little. If Redis is already the source of truth for the data being queried, adding Elasticsearch or OpenSearch means a second copy, a change-data-capture or dual-write path, and two systems to keep consistent. RediSearch removes that path entirely, at the cost of the memory constraint and the loss of self-managed sharding.

There is also a query-surface difference worth naming. RediSearch's aggregations engine and its vector similarity search live in the same query language as the text search, so a filtered KNN query is one command. In a dedicated engine, vector search is typically a separate index type with its own query path. Which arrangement is simpler depends on whether your filters and your vectors describe the same documents.

Licence, maintenance and the cost of upgrading

Licensing changed with Redis 8. The README states that starting with Redis 8, RediSearch is licensed under your choice of the Redis Source Available License 2.0 (RSALv2), the Server Side Public License v1 (SSPLv1), or the GNU Affero General Public License version 3 (AGPLv3), and that prior versions remain subject to the first two. The repository's LICENSE field reports NOASSERTION, which is consistent with a choice-of-licence arrangement rather than a single identifier. The README directs readers to the license folder for full terms. Whether any of these options fits your deployment is a question for your own legal review, not something this article can settle.

Maintenance is best read from the release lines. The most recent releases are v2.10.31, v2.8.38 and v2.6.37, all published on 2026-06-17, and the README carries badges marking the latest maintenance release for each of 2.10, 2.8 and 2.6. Three parallel maintenance lines means fixes are backported rather than landing only on a single head. The last push to the repository was on 2026-09-15.

The upgrade cost changed shape with Redis 8. Because the Query Engine is now integral to Redis, upgrading search means upgrading Redis. The README states that standalone versions are no longer released, so there is no separate module artefact to pin. Teams that previously tracked RediSearch releases independently now track the server. The README does not document a rollback procedure for an index or a server upgrade, so treat the upgrade path as forward-only until you have confirmed otherwise in the documentation.

Editorial conclusion

Adopt RediSearch if your data already lives in Redis and you want search without a second datastore, and if you can run Redis 8 or a maintained 2.10 build. Do not adopt it as a general-purpose replacement for a dedicated search cluster, and do not build a multi-node topology on the open source module, because distributed RediSearch is only available in Redis Cloud and Redis Enterprise Software. Before committing, verify the licence text in the licenses folder for the exact version you deploy, and check whether your host's Redis build already includes the Query Engine.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. RediSearch/RediSearch on GitHub
5. Releases