Redis Vector Database: Vector Search and RAG in Java

Redis works as a vector database through two distinct mechanisms: vector fields in the Redis Query Engine, and vector sets, a native data type introduced in Redis 8. Both store embeddings and retrieve records by semantic similarity rather than exact match, which is the capability behind semantic search, recommendation engines, and retrieval-augmented generation (RAG).

The more useful question is not whether Redis can do this. It can. The question is whether reusing the Redis instance you already operate beats adding a dedicated vector database to your stack. This guide covers how vector storage and indexing work in Redis, where Redis outperforms purpose-built vector stores, where it genuinely doesn't, and how to work with both approaches from Java.

What makes a database a vector database

A vector database stores embeddings: fixed-length arrays of floating-point numbers produced by a machine learning model. A sentence, an image, or an audio clip goes in; a few hundred to a few thousand numbers come out. The useful property is that inputs with similar meaning produce vectors that sit close together in high-dimensional space, so proximity becomes a proxy for semantic similarity.

That changes the shape of the query. A traditional index answers "which rows contain this term." A vector index answers "which rows are closest to this point." Nothing is matched exactly, and the result is ranked by distance rather than filtered by predicate.

Any system that calls itself a vector database has to do four things:

• Store vectors efficiently, usually alongside the source record and its metadata.
• Index them so queries don't degrade into a full scan of every embedding.
• Search by distance using a metric appropriate to the embedding model.
• Filter by metadata, so similarity can be constrained by ordinary business rules such as tenant, category, or date.

The fourth requirement is where architectures diverge most sharply, and it's the one that decides whether a separate vector store is worth its operational cost.

How Redis works as a vector database

Redis offers two paths to vector storage, and they suit different problems. Choosing between them is the first real decision.

The Query Engine versus vector sets

The Redis Query Engine (the capability behind Redis Search) treats a vector as one field type among many. You declare a VECTOR field in an index schema next to text, numeric, tag, and geospatial fields, then query across all of them together. Embeddings usually live inside Redis JSON documents or hashes, indexed by key prefix.

Vector sets are a native data type added in Redis 8. They store embeddings directly against an element name and perform similarity search without a secondary index, which makes them considerably simpler to reason about. They also support quantization, which reduces the memory cost of large collections substantially.

As a rule: if your query is "find things like this," reach for vector sets. If it's "find things like this, in this category, under this price, updated since last week," you want the Query Engine.

FLAT and HNSW indexing

Vector indexes trade accuracy against latency, and Redis exposes both ends of that trade.

FLAT compares a query against every vector in the index. Results are exact, recall is perfect, and query time grows linearly with the collection. It's the right choice for smaller datasets and the correct baseline when benchmarking anything else.

HNSW (Hierarchical Navigable Small World) builds a layered graph that lets the engine skip most of the dataset while walking toward the nearest matches. Results are approximate, but latency stays workable into the millions of vectors. This is what production deployments use.

The practical difference is that HNSW introduces a recall parameter you now own. An approximate index that returns the wrong neighbors is a correctness problem that surfaces as vague, subtly wrong answers rather than as an error. Benchmark HNSW output against a FLAT index on the same data before trusting it. For the index definitions, query syntax, and Java code behind both, see our guide to Redis Search.

Distance metrics

The distance metric must match the embedding model that produced your vectors. COSINE measures the angle between two vectors and is the usual choice for text embeddings, where direction carries the meaning and magnitude does not. L2 measures straight-line Euclidean distance and suits image features and spatial data. IP (inner product) measures the dot product; on vectors already normalized to unit length it ranks results identically to cosine.

This is not a tuning knob. Pairing a model with the wrong metric produces plausible-looking results that are quietly incorrect, which is far harder to diagnose than an outright failure.

Memory footprint: the real constraint

Redis holds its dataset in RAM, and that is the binding limit on vector workloads far more often than query throughput is.

The arithmetic is unforgiving. A 1,536-dimension embedding stored as 32-bit floats occupies roughly 6 KB before any index overhead. A million of them is around 6 GB of raw vector data, plus the HNSW graph, plus the source documents, plus whatever else your Redis instance is already doing. Ten million puts you well into territory where a dedicated, disk-backed store starts to look reasonable.

Three levers help. Quantization, available with vector sets, cuts precision per component in exchange for a large memory reduction and a small recall cost. Smaller embedding models often perform nearly as well as large ones for retrieval while producing vectors a quarter the size. And Redis Cluster partitions the workload horizontally across nodes.

Estimate your memory ceiling before committing to an architecture. It's the calculation that most often changes the answer.

Redis versus dedicated vector databases

The honest comparison is not feature-by-feature, because dedicated vector databases will win that on vector features alone. It's whether their advantages justify running a second system.

When Redis is the right choice

Redis wins decisively when your embeddings live near data you already keep in Redis. A query such as "find products semantically similar to this one, in the footwear category, currently in stock" executes as a single operation with a pre-filter applied before the vector comparison. Split across two systems, the same query becomes a round trip to a vector store, a set of returned IDs, and a second lookup to filter them — with the failure mode that aggressive filtering leaves you with too few results and forces a retry at a higher k. A single RSearch index can combine vector similarity with full-text, numeric, tag, and even geospatial filters in one request.

It also wins on latency and on operational surface area. Keeping retrieval in the low single-digit milliseconds matters when vector search sits inside a RAG pipeline whose total budget is already consumed by an LLM call — and colocating vectors with their metadata removes a network hop that a two-system architecture cannot avoid. Meanwhile, a system you already monitor, back up, secure, and know how to scale costs far less than the same competence acquired for a second database.

Choose Redis when your corpus is in the millions rather than the billions, when embeddings are one attribute of records that also carry business metadata, when latency is tight, and when you'd rather not operate another datastore.

When a dedicated vector database is worth it

Dedicated stores earn their place at scale. Beyond roughly ten million vectors, keeping everything in RAM becomes expensive relative to a disk-backed index built for exactly this job. If vector search is your product rather than a feature of it, the specialized tooling — index tuning, recall diagnostics, reranking, hybrid sparse-dense retrieval — is worth having.

They're also the better fit when your vector workload has a completely different scaling profile from the rest of your stack, or when a managed service meaningfully reduces your operational burden. And if your embeddings have no relationship to data in Redis, the main argument for colocation disappears.

The pattern that fails is adopting a dedicated vector database at a scale where Redis would have been sufficient, and paying the integration cost — two consistency models, two failure modes, two-phase queries — for headroom you never use.

What teams build with it

Semantic search

Retrieval by meaning rather than keyword. Combining a vector field with full-text search in one index gives you hybrid retrieval, where lexical precision and semantic recall complement each other instead of competing.

Retrieval-augmented generation

RAG grounds an LLM in your own content. A user question is embedded, the nearest document chunks are retrieved, and those chunks are injected into the prompt as context. Retrieval quality determines answer quality entirely — an LLM cannot recover from being handed the wrong passages — which is why metadata filtering matters as much as raw similarity. Restricting retrieval to documents a user is permitted to see is a vector search problem with an authorization constraint attached.

Recommendation engines

Item and user embeddings turn "customers who liked this" into a nearest-neighbor lookup, with the cold-start advantage that a new item is recommendable from its content embedding before anyone interacts with it.

Semantic caching for LLM applications

An underused pattern that suits Redis particularly well. Rather than caching on exact prompt match, embed the prompt and return a cached response when a previous prompt sits within a similarity threshold. Semantically equivalent questions phrased differently hit the cache, cutting both latency and token spend. It's a natural extension of Redis caching into AI workloads.

Using Redis as a vector database from Java

Redis has no native Java support, so the client determines how much of this is pleasant to work with. Redisson exposes both vector approaches through typed Java APIs rather than raw command strings:

A vector field is declared alongside ordinary fields in the same schema, so hybrid queries need no special handling:

RSearch s = redisson.getSearch(StringCodec.INSTANCE);

s.createIndex("product_idx", IndexOptions.defaults()
                                 .on(IndexType.JSON)
                                 .prefix(Arrays.asList("doc:")),
                                 FieldIndex.text("$.description").as("description"),
                                 FieldIndex.tag("$.category").as("category"),
                                 FieldIndex.flatVector("$.embedding")
                                           .type(VectorTypeParam.Type.FLOAT32)
                                           .dim(1536)
                                           .distance(VectorDistParam.DistanceMetric.COSINE));

Full index definitions, KNN query syntax, and the byte encoding required for query vectors are covered in our Redis Search guide. For vector sets, see our Java developer's guide to vector sets.

Two things matter beyond the API surface. Redisson abstracts the deployment topology, so the same code runs against Standalone, Sentinel, or Cluster with only configuration changing — useful when a prototype on a single node has to become a clustered production service. And Redisson PRO adds data partitioning, which distributes a single large structure across cluster nodes rather than confining it to one hash slot — relevant to any workload where a single node's memory becomes the ceiling.

One integration detail is worth knowing before you start. The Redis vector store implementations shipped by Spring AI and LangChain4j are built on Jedis, not Redisson — Spring AI's RedisVectorStore takes a JedisPooled instance, and LangChain4j's RedisEmbeddingStore calls Jedis directly. An application already using Redisson will therefore run two Redis clients side by side if it adopts either. If you'd rather not, RSearch provides the same indexing and query capability through the connection pool, cluster configuration, and codecs you already have.

Valkey as a vector database

If your stack runs Valkey rather than Redis, the picture differs. Valkey forked before vector sets existed and does not have that data type. Vector search instead comes from valkey-search, an official module compatible with Valkey 8.1.1 and above under a BSD-3-Clause license.

It is not a reduced implementation. valkey-search provides FT.CREATE and FT.SEARCH, supports HNSW for approximate search and KNN for exact matching, indexes both Hash and JSON data types, and handles hybrid queries that combine vector similarity with numeric, tag, and text filters. Its query planner chooses between pre-filtering and inline filtering based on how selective the filter is.

For teams weighing a migration, the practical takeaway is that vector search is not a reason to stay on Redis. Query syntax is shared, and both engines expect vectors encoded as 32-bit IEEE 754 floats in little-endian byte order, so the encoding logic in your application is portable. The genuine difference is vector sets, which remain Redis-only. Redisson supports both engines through the same API.

Choosing the right approach

For Java teams choosing to keep vectors in Redis or Valkey, the client is the next decision. Redisson exposes both vector approaches as typed Java APIs, abstracts the deployment topology, and — in Redisson PRO — removes the single-node memory ceiling that otherwise limits vector workloads on a cluster. To see what's included, compare Redisson and Redisson PRO.

Similar terms

• Redis
• Redis Architecture
• Redis Caching
• Redis Cluster
• Redis Data Types
• Redis Hash
• Redis JSON
• Redis Search