Redis Introduces a Multi‑Threaded Query Engine to Boost Vector Search Performance for Generative AI

Redis, the widely used in‑memory data‑structure store, has released an enhanced Redis Query Engine at a time when vector databases are gaining prominence for retrieval‑augmented generation (RAG) in generative AI.

The new engine incorporates multithreading, allowing concurrent access to indexes, which enables vertical scaling and significantly raises query throughput while keeping latency low.

Redis stresses that this improvement is especially critical when data volumes reach hundreds of millions of documents, as complex queries can otherwise throttle throughput; the company claims sub‑millisecond response times and average query latency under 10 ms.

The traditional single‑threaded architecture has limitations: long‑running queries can cause congestion, particularly when using inverted indexes for data search.

Search operations are not O(1); they typically combine multiple index scans, each completing in O(log n) time where n is the number of indexed points.

The new multithreaded approach effectively resolves these challenges, dramatically boosting throughput for compute‑intensive tasks such as vector similarity search while preserving high performance for simple operations.

Redis notes, “Efficiently scaling search requires a combination of horizontal data distribution (scale‑out) and vertical multithreaded processing (scale‑up) that enables concurrent index access.”

The engine follows a three‑step workflow: query planning occurs on the main thread and tasks are queued to a shared queue; worker threads pull tasks and execute query pipelines concurrently; results are sent back to the main thread, allowing it to continue handling other Redis commands.

Redis claims this architecture lets the system handle multiple complex queries while keeping the main thread responsive to standard Redis operations, thereby improving overall system throughput and scalability.

Extensive benchmarks compare the new engine against three categories of vector‑database providers—pure vector databases, general‑purpose databases with vector capabilities, and fully managed in‑memory Redis cloud services—showing superior speed, scalability, and overall performance over the alternatives.

The vector‑database market has exploded recently, making it difficult for new products to stand out; experts note the market is saturated and differentiation is challenging.

Reddit senior engineer Doug Turnbull observes that the sheer number of vector‑search options overwhelms users, and that the real difficulty lies not just in obtaining vectors but in everything surrounding them.

This perspective underscores the need for comprehensive solutions to address broader AI‑driven data‑retrieval challenges.

Redis states the new engine delivers up to a 16× increase in query throughput compared with the previous generation, meeting the stringent demands of generative‑AI applications such as real‑time RAG chatbots that must process multiple steps quickly.

Gmail founder Paul Buchheit’s “100 ms rule”—that each interaction should complete within 100 ms to feel instantaneous—is cited as a target for user experience.

Latency breakdowns in RAG architectures (network RTT, LLM processing, application logic, vector‑DB query) result in an average end‑to‑end response time of about 1.5 seconds; developers must redesign data architectures to approach the 100 ms goal for real‑time generative AI.

Vectera’s Ofer Mendelevitch reminds us that while vector‑DB performance is important, it is only one piece of the larger AI‑application stack.

RAG remains the most popular method for building trustworthy LLM applications that rely on strong semantic search, yet the vector database is just one layer of the overall stack.

RisingWave Labs founder Wu Yingjun adds that instead of investing in new vector‑database projects, developers should focus on enhancing existing databases with vector engines to make them more powerful.

Redis’s strategy of augmenting its existing infrastructure aligns with this view, offering developers a more integrated and efficient solution.

Benchmark methodology covers both ingestion and search workloads: ingestion uses hierarchical navigable small world (HNSW) and approximate nearest neighbor (ANN) algorithms; queries focus on k‑nearest‑neighbor (k‑NN) searches, measuring requests per second (RPS) and average client latency, including round‑trip time (RTT).

Tests employ datasets such as gist‑960‑euclidean, glove‑100‑angular, deep‑image‑96‑angular, and dbpedia‑openai‑1M‑angular, featuring varied vector dimensions and distance functions; the environment uses industry‑standard tools like Qdrant’s vector‑db‑benchmark for reproducible results.

The new query engine is already available in Redis Software and is slated for release in Redis Cloud later this autumn.