RedisJSON: the JSON data type that folded into Redis itself

A module whose headline is that you no longer need it

The first thing the README says is a retirement note, not a feature list. Starting with Redis 8 the JSON data structure is integral to Redis and does not need to be installed separately. The note is unambiguous about direction: no new standalone versions of RedisJSON, only patches to old versions, with the pointer to redis/redis as the place to look.

That reframes what the repository is. It is not a product you are expected to install fresh; it is the source of a data type that got absorbed, plus a maintenance line for anyone still running Redis 6 or 7 with the module loaded. GitHub reports 3,947 stars, 337 forks and 181 open issues on a Rust project with no open deprecation banner, and the last push was 2026-09-23, inside the window where recent activity still counts as live. Those two facts sit next to each other without contradiction: code still moves, releases still ship, but they ship patches rather than features.

The module itself is described as implementing ECMA-404, the JSON Data Interchange Standard, as a native data type, which lets you store, update and fetch JSON values from Redis keys. Full support of the standard, JSONPath selection, binary storage in a tree structure, typed atomic operations for every JSON value type, and secondary indexes when paired with RediSearch. That is a short feature list by module standards, and it is accurate to what the code actually is.

Two crates, one workspace, several pinned dependencies

The build is a Cargo workspace with two members, `json_path` and `redis_json`, which is a good clue about where the difficulty lives. Parsing JSON is table stakes; evaluating a path expression against an arbitrarily shaped document, correctly, is where the work is. Splitting the path evaluator into its own crate means it can be tested and reasoned about separately from the Redis command surface.

The dependency list in `Cargo.toml` is where a mature infrastructure project shows its scars. Several pins come with a comment explaining why:

# Pin serde_json below the version range that switched float formatting (ryu -> zmij),
# to keep exponent formatting stable (e.g. `e308` vs `e+308`) and avoid test churn on `cargo update`.
serde_json = { version = ">=1.0.0, <1.0.147", features = ["unbounded_depth"] }

# Pin home crate to 0.5.11 for Alpine Linux Rust 1.87 compatibility
# [email protected]+ requires Rust 1.88
home = "=0.5.11"

A JSON module that formats a number as `e308` in one version of a dependency and `e+308` in the next is a module whose clients will diff their test output for no good reason. Pinning serde_json below the float formatting change and pinning `home` below the Rust version it demands are both signs of a project that has been asked to build on someone else's schedule and decided to hold its ground. The module itself is pulled from a git tag rather than crates.io:

redis-module = { git = "https://github.com/RedisLabsModules/redismodule-rs", tag = "v2.1.3", default-features = false, features = [
    "min-redis-compatibility-version-7-4",
] }

The workspace declares edition 2021 and the license field in the manifest mirrors the README's triple option.

Three parallel release lines, all patched on the same day

The release list is the clearest evidence of the maintenance posture. Versions 2.8.19, 2.6.24 and 2.4.19 were all published on 2026-04-28, within about five minutes of each other, and they carry the same three bug fixes: trailing characters ignored, wrong mutation ordering for array commands with recursive paths, and a batch of JSONPath evaluation issues.

Three lines in maintenance at once is not a project that is planning a feature. It is a project supporting three generations of Redis at once, which is exactly what you want from a module embedded in the server layer. If you run Redis 7.2 you get 2.6, if you are on the 2.4 line you get 2.4, and neither is being asked to grow.

The wording in the notes is worth reading closely. Update urgency is `MODERATE`, which the release spells out as programming an upgrade of the server but not rushing it. Nobody is presenting these as fixes for data loss or corruption, and the specific fixes are correctness fixes in path evaluation and mutation ordering rather than availability ones. If you are on an old line, the patch is worth scheduling, and it is worth reading the linked issues first to see whether your usage pattern is the one that was affected.

Where the license story disagrees with itself

Here is a genuine disagreement inside the project, and it is worth resolving before you build on either answer.

The README states that from Redis 8 onward RedisJSON is licensed under your choice of three: the Redis Source Available License 2.0, the Server Side Public License v1, or the GNU Affero General Public License version 3. It also says prior versions remain subject to only the first two, and points at the license folder for full terms. The workspace manifest agrees, naming all three in the `license` field.

Against that, GitHub reports the repository's license field as `NOASSERTION`, which is what the API returns when a license cannot be classified automatically rather than when a license is absent. The repository does contain `LICENSE.txt` and a `licenses/` directory at the top level, so the text is there. The practical upshot is that the authoritative statement is the README plus the license files, and the metadata field is simply not carrying the information. Anyone doing automated license compliance checks will see an unresolved field and should read the README section instead of treating `NOASSERTION` as a finding.

Contributions are covered separately. The README says that contributing by pull request, code fragment, private email or public discussion all mean agreeing to the Redis Software Grant and Contributor License Agreement, pointing at CONTRIBUTING.md, with security issues handled through SECURITY.md.

Building the module the way the Dockerfile does it

The top level of the tree is mostly build infrastructure, and it is thorough. There are Dockerfiles for Alpine, bookworm, bullseye, focal, jammy, noble, trixie, rocky8, rocky9, rocky10, amazonlinux2, amazonlinux2023, alma8, alma9, alma10, azurelinux3, mariner2 and bionic, plus a Makefile driven by a vendored `deps/readies/mk/main` include and an `.install/` script for bootstrapping system packages, Python and Rust.

The default Dockerfile shows how the pieces come together. It builds the module against a pinned Redis, copies the resulting shared object into `/usr/lib/redis/modules/`, and then loads two modules at server start:

CMD ["redis-server", \
     "--loadmodule", "/usr/lib/redis/modules/rejson.so", \
     "--loadmodule", "/usr/lib/redis/modules/redisearch.so"]

Redisearch is not incidental. Secondary indexes only exist when the module is loaded next to RediSearch, which is why the Dockerfile bundles them and why the README lists index support as conditional on that pairing. If you have ever stored JSON in a Redis hash and then wanted to query into it, the index is the piece that makes it possible.

The Makefile's help text mentions a nightly toolchain, a debug variant, LLVM sanitizers by type and a Valgrind build. For a crate that manipulates a binary tree of arbitrary depth inside a database process, having sanitizer targets in the build menu is a reasonable thing to want.

What a reader should take away from a thin README

The README is 2,770 characters and most of it is badges, two notes, a license section and a contribution section. It links all documentation to redis.io rather than to the `docs/` directory that exists in the tree. That is the right call for a project whose feature now lives in the server, and it means there is nothing to learn from this page beyond the direction of travel and the terms.

For anyone deciding whether to keep the module, the concrete checks are short. If you are on Redis 8 or later you should be using the built-in JSON type and reading the command reference for JSON.SET, JSON.GET and the JSONPath syntax on redis.io. If you are on an older Redis and the module is loaded, the 2.4, 2.6 and 2.8 patches from 2026-04-28 are all marked `MODERATE` urgency, and the open issue count of 181 is where you would find out whether the JSONPath issues matter for your documents. If you are evaluating the design itself, `json_path/` and `redis_json/` are the two directories worth reading, and the pinned dependency comments are a better guide to the project's real priorities than any feature list would be.

What the README does not settle, and cannot, is why a given version of Redis has the module when another does not, or how the built-in type compares to the standalone 2.8. Those answers live in the Redis repository, not this one.

Editorial conclusion

RedisJSON is in an unusual position for a popular module: the feature won and the standalone project is retiring on purpose. The repository still holds the only interesting parts of the story, a JSONPath implementation and a set of typed atomic update commands, and it is still being pushed to, with the last commit landing on 2026-09-23. What has stopped is the standalone release train, with 2.8.19 published on 2026-04-28 and a note that no new standalone versions are coming. If you are picking an approach today, the decision is Redis 8 with JSON built in, not a module from this repo, and the thing to read before you decide is the command reference on redis.io rather than the README, which is now mostly a redirect notice and a licensing statement.

Frequently asked questions

Official sources

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