Redis OM Spring and document repositories on top of Spring Data Redis

The repository pattern, pointed at Redis

Redis OM Spring extends Spring Data Redis to take full advantage of Redis, and it does so by adding rather than replacing. The README states that it provides all Spring Data Redis capabilities, plus a list of extensions.

The core addition is the @Document annotation to map Spring Data models to Redis JSON documents. On top of that, there is an enhancement to the Spring Data Redis @RedisHash via @EnableRedisEnhancedRepositories, which uses Redis' native search engine, RediSearch, for secondary indexing, and which uses ULID for @Id annotated fields. ULID is a sortable identifier, lexicographically sortable by creation time, which is a better fit for a document store than a random UUID and a better fit than an auto-increment.

RedisDocumentRepository gives automatic implementation of Repository interfaces for complex querying, enabled through @EnableRedisDocumentRepositories. The point is that a Spring developer writes a repository interface and gets a working implementation without writing a query layer by hand.

The Redis OM family of client libraries provide high-level abstractions, idiomatically implemented for your language and platform, and currently covers the Node, Python, .NET and Spring communities. The audience is a Spring developer who has decided that Redis is where the documents go, and who does not want to hand-write RediSearch queries to get them back out.

Search, vectors and the Bloom annotation

The index features come in three flavours, and they map onto the three things people actually want from Redis.

Declarative search indexes come from the @Indexed annotation, full-text search indexes from @Searchable. Both are annotations on the mapped model, and both end up as RediSearch index definitions, which means the schema of your query is derived from the schema of your class rather than maintained separately.

The @Bloom annotation is the one worth understanding. It determines, with and with high degree of certainty, whether a value is in a collection, using a Bloom filter. In Redis terms that means a fast membership test backed by a probabilistic structure rather than a scan, and for a collection of document identifiers it turns an O(n) check into something close to constant time. The README's careful phrasing, with and with high degree of certainty, is the right framing, because a Bloom filter can report a false positive but never a false negative.

The @Vectorize annotation generates embeddings for text and images, for use in Vector Similarity Search, and the Vector Similarity Search API is documented against Redis Stack Vectors. That is a meaningful addition for a document store, since it means the same repository and index machinery covers semantic lookup as well as field queries.

Dynamic index naming and multi-tenant support come with SpEL expressions and RedisIndexContext, so a single application can serve several tenants with separate index namespaces derived at runtime rather than one hardcoded index per model.

EntityStreams and the entity meta-model

EntityStreams is the feature that goes furthest beyond the Spring Data idiom. The README describes it as Streams-based Query and Aggregations Builder, and the table of contents gives the two sections it appears in: Querying with Entity Streams, and Entity Meta-model.

A repository interface with a derived query method covers the case where the query shape is known at compile time. EntityStreams covers the case where it is not, letting you build a query incrementally and then run an aggregation over the result, in the style of a stream pipeline rather than a repository method name.

The entity meta-model is the companion to that. It is the reflection layer that knows the shape of your mapped entities, which is what makes the stream builder able to constrain on a field without you writing the key name as a string.

Taken together, the repository and the stream API cover the two ways you query in Spring Data. The repository is the familiar compile-time-checked path, and EntityStreams is the dynamic path for reports and aggregations that are assembled at request time. That combination is what makes this more than a search wrapper.

Migrating an index without downtime

The index migration service is the feature that suggests this is aimed at production rather than demos, and it comes with three strategies: Blue-Green, Dual-Write and In-Place.

An index in RediSearch is a schema, and changing a schema means reindexing. In-Place does that on the live index. Blue-Green builds a new index alongside the old one and switches over. Dual-Write writes to both during the transition.

This matters because the mapping between a Java class and a search index is derived from the class, so changing a field type or a set of indexed attributes means the stored data and the index disagree until the index is rebuilt. A library that only offers in-place reindexing forces a window where queries return wrong results. Offering three strategies lets you pick the cost you can afford, and the presence of the choice is a signal that the maintainers have had to do this in production.

The README also documents the repository layout, and the demos directory is worth a look before adopting, because there are both embedded demos and external demos, which is a distinction that tells you whether a demo needs a running Redis or embeds one.

Getting Redis Stack running first

Nothing works until you have the right Redis, and the README is direct that Redis OM Spring relies on the search, query and JSON capabilities of Redis Stack.

The quickest route is Docker, and the command exposes both the Redis port and the RedisInsight port:

docker run -p 6379:6379 -p 8001:8001 redis/redis-stack

Redis Stack is an extension of Redis that adds several modern data structures, and opening http://localhost:8001 gives you the redis-insight GUI to visualise and work with your data. A Docker Compose YAML file is also provided for getting started with Redis Stack.

The compose file in the repository root is minimal and worth comparing with the README command:

name: redis-om-spring
services:
  redis:
    image: "redis/redis-stack:edge"
    ports:
      - "6379:6379"
    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

Note the image tag. The compose file uses redis/redis-stack:edge, the edge build, while the README command uses the stable redis/redis-stack. That is a meaningful difference for a project you intend to depend on, since edge means a moving target and you are likely to see behaviour changes that the released version does not have. For evaluation the stable image is the saner choice.

Version lines, dependencies and what to check first

The compatibility table in the README is the most operationally important thing in it, and it is presented with an instruction: always use the Redis OM Spring version that matches your Spring Boot version.

The table maps the library lines to Spring Boot and Java versions, and gives each a status. The 1.0.x line targets Spring Boot 3.4.x with Java 17 or later and is in maintenance. The 1.1.x line targets Spring Boot 3.5.x with Java 17 or later and is the current stable. The 2.0.x line targets Spring Boot 4.0.x with Java 17 or later and is the latest.

So a project on Spring Boot 3.4 is on a maintenance line, a project on 3.5 gets the current stable, and only Spring Boot 4.0 users get the newest code. That is a deliberate three-line structure rather than one line with a wide range, and it means the library is versioned against the framework, not independently.

The releases visible on the repository are v2.0.10, v1.1.7 and v1.0.10, all dated 2026-09-01, which tells you the three lines are maintained in parallel and released together.

The build is Gradle with a gradlew wrapper, a .java-version file, and a .spotless directory with a separate spotless.gradle, so code formatting is enforced. There is also a redis-om-spring-ai module in the tree, a ymlreleaser configuration for release automation, and an AGENTS.md file. The licence is MIT, and the project links a troubleshooting section and a section on obtaining RediSearch and RedisJSON, both of which are worth reading before you hit a problem.

Editorial conclusion

Redis OM Spring is a good fit for a Spring Boot service that wants to keep its repository abstraction while storing JSON documents in Redis, because it adds @Document mapping, RediSearch secondary indexes and EntityStreams on top of Spring Data Redis rather than replacing it, and it includes an index migration service for changing an index without downtime. It is a poor fit if you run plain Redis without the Stack modules, since search, JSON and vector features all depend on them, and a poor fit if you want the widest possible Spring Boot range, because the lines are split across 1.0.x, 1.1.x and 2.0.x with one of them in maintenance. Before adopting, pick the release line that matches your Spring Boot major version, confirm your Redis deployment is Redis Stack rather than open-source Redis, and read the troubleshooting and demo sections of the documentation, which the readme links rather than reproduces.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. redis/redis-om-spring on GitHub
5. Releases