Redis 8.2 and its vector support: when it actually makes sense
Updated: 2026-07-07
Redis 8.2 has moved vector search from an optional extension to a first-class data type. This is more relevant than it looks because it shifts the usual question: it is no longer whether Redis can hold embeddings, but whether it replaces a dedicated engine like Qdrant, Weaviate, Milvus or the pgvector extension on PostgreSQL.
Key takeaways
-
In Redis 8.0, vector search stopped living in a separate module and became part of the open Redis core (Redis Open Source); 8.2 added SVS-VAMANA, a compressed vector index type, plus performance improvements.
-
In its own benchmark, Redis reports up to 4x lower latency than Qdrant under concurrent load and up to 9.5x higher throughput than pgvector on Aurora PostgreSQL. Those are vendor-published numbers, so read them with that filter on.
-
Redis wins when the application already uses Redis for cache, sessions, or queues: consolidating systems has real operational value.
-
Past a few million vectors, the disk-persisted indices of Qdrant or Milvus outweigh Redis’s fully in-RAM index.
-
HNSW does not handle mass deletions well: a high deletion rate fragments the graph and eventually forces a full index rebuild.
What changed since the RediSearch extension
Until Redis 7.x, vector search lived inside the RediSearch module, with a separate license and the habit of behaving differently depending on the exact module version loaded. In 8.0, Redis merged Redis Stack and Redis Community Edition into a single distribution (Redis Open Source) and folded RediSearch, vector search included, into it with no separate modules to manage. 8.2 added SVS-VAMANA, a new compressed vector index type meant to shrink HNSW’s memory footprint, plus a long list of performance improvements documented in the release notes.
The important shift is that the vector layer is no longer a fragile add-on. It is part of the engine the team already knows. Vectors are fields inside hash or JSON documents, the HNSW index is built in memory, and queries use the same RediSearch language already used for full-text search. A single query can combine boolean filters on tags with a KNN search over embeddings without crossing systems.
Performance: what the vendors themselves report
Worth being upfront about the source here: the most-cited performance numbers come from Redis itself, and Qdrant publishes its own on the other side, so neither is a neutral referee. That said, both benchmarks are reproducible and use public datasets, which at least makes them checkable.
Redis, in its vector database benchmark[1], compares itself against Qdrant 1.7.4, Milvus 2.4.1, and Weaviate 1.25.1 on datasets like gist-960-euclidean (1 million vectors, 960 dimensions) and dbpedia-openai-1M-angular (1 million vectors, 1,536 dimensions), and reports up to 3.4x higher queries per second than Qdrant and up to 4x lower latency under concurrent load, at matching recall. Against Aurora PostgreSQL 16.1 with pgvector 0.5.1, Redis claims up to 9.5x higher throughput and up to 9.7x lower latency. Qdrant, for its part, publishes its own benchmarks[2], where its engine reaches the highest queries-per-second and lowest latency in nearly every scenario it tests, including against Redis.
My reading, with that caveat up front: the gap is real but not an order of magnitude in most cases, and where Redis wins clearly is when the application already depends on Redis for cache, sessions, or queues. Avoiding an additional system has real operational value: fewer backups, less monitoring, fewer permissions, fewer pipes that can break.
GraphRAG flow diagram showing the relationship between embeddings, vector search, and augmented generation, the use case Redis 8.2 serves for medium-sized corpora
Where a dedicated engine still wins
Past a few million vectors the story changes. Redis’s HNSW index lives entirely in memory: the raw vectors alone, before the graph, cost roughly 4 bytes per dimension per vector (float32). Run the math on 50 million vectors at 768 dimensions and you land around 150 GB of RAM, before even adding the HNSW graph itself. Qdrant and Milvus support disk-persisted indices with a hot cache layer, which lets them serve large corpora on much more modest hardware.
The second area where a dedicated engine wins is advanced filtering. Redis supports boolean filters on tags and numeric ranges, but Qdrant and Weaviate offer geospatial filters, rich payloads, and adaptive pre-selection strategies. The higher the filter cardinality, the more Redis’s planner shows it has less information about real selectivity than an engine built from the ground up for filtered search.
The piece people often forget: ingestion
Talking about search is only half the work. Redis has the advantage of in-memory writes with very low latency: in its own benchmark against pgvector on Aurora PostgreSQL, Redis reports indexing times 5.5 to 19 times faster. For corpora rebuilt daily, that ingestion speed matters as much as query speed.
The downside is that HNSW does not handle mass deletions well. Most implementations do soft deletes: they mark a vector as removed instead of pulling it out of the graph, and queries keep walking past those "ghost" nodes until someone rebuilds the index. The higher the deletion rate, the sooner you need to rebuild to avoid losing recall. Redis does not yet expose an incremental rebuild operation, so in practice the pattern that works is rebuilding the full index in batches. Dedicated engines like Qdrant offer asynchronous compaction that avoids this gymnastics, and for document flows with heavy churn that difference matters.
Coherence with the rest of Redis
The detail that makes Redis 8.2 interesting for many cases is not so much raw performance as operational coherence with the rest of the system. If the team already handles replication, backups with RDB and AOF, failover with Sentinel or Cluster, and eviction policies, that experience applies directly to vector indices. There is no new system to learn and no different consistency model to explain to the on-call rotation.
This value grows the smaller the team. In an organization with two or three people running infrastructure, adding Qdrant or Weaviate means a new binary, a new management protocol, a new backup pattern, and new alerts. Redis 8.2 reuses most of what already works. For a team of fifteen with a dedicated SRE, that advantage fades quite a bit.
How to decide
My practical rule is simple:
-
Redis 8.2 by default if: the vector corpus fits in RAM on a reasonable machine, the application already uses Redis, and filters are basic. The operational saving outweighs any specific advantage a dedicated engine might have.
-
Dedicated engine if: the corpus exceeds 10 million vectors, filters are complex, or there are very large retention requirements with rare access.
-
Middle zone (1 to 10 million vectors): depends on the query pattern. If queries are highly concurrent and latency-sensitive, Redis wins. If they are sparse but hit large, rotating corpora, Qdrant or pgvector win.
Redis 8.2 closes a gap it had been carrying since RediSearch added vector search back in 2022. With the index built into the open core, Redis starts competing seriously with pgvector in the medium corpus range, and that is a category shift for the platform. I do not think it replaces dedicated engines in the high segment, but for most RAG applications at mid-sized companies, where the corpus is a few million vectors and filter complexity is low, Redis 8.2 is a sober, sufficient option. Every extra system in production has hidden cost in staff, monitoring, and security. If the case fits, using Redis for both cache and embeddings is one of those decisions that reduce complexity without losing capability.
Versión en español: Redis 8.2 y su soporte vectorial: cuándo tiene sentido.
