RedisJSON Is Useful When You Update Parts of a Document

I would not use RedisJSON just because my payload happens to be JSON.

I would use it when I need fast reads and updates against parts of a document without fetching the whole blob, changing it in app code, and writing it back.

Here is the problem.

{
  "id": "user:42",
  "name": "Mark",
  "plan": "free",
  "profile": {
    "city": "Toronto",
    "skills": ["React", "Java", "Redis"]
  },
  "usage": {
    "posts": 23,
    "revisions": 4
  }
}

If this lives as a plain string in Redis, changing usage.revisions means:

1. GET user:42
2. Parse JSON in the app
3. Modify one field
4. SET user:42 ...

That is boring code, and boring code becomes dangerous when two requests update different fields at the same time.

RedisJSON gives you path-level commands instead.

Run It Locally

Use Redis Stack if you want the quickest local setup:

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

Then connect:

redis-cli

Store a Document

JSON.SET user:42 $ '{
  "id": "user:42",
  "name": "Mark",
  "plan": "free",
  "profile": {
    "city": "Toronto",
    "skills": ["React", "Java", "Redis"]
  },
  "usage": {
    "posts": 23,
    "revisions": 4
  }
}'

Read the whole thing:

JSON.GET user:42

Read one field:

JSON.GET user:42 $.profile.city

That is the first real win. You can ask for the part you need.

Update One Field

Upgrade the user:

JSON.SET user:42 $.plan '"pro"'

Increment a counter:

JSON.NUMINCRBY user:42 $.usage.revisions 1

Append a skill:

JSON.ARRAPPEND user:42 $.profile.skills '"Three.js"'

Read it back:

JSON.GET user:42 $.plan $.usage $.profile.skills

This is where RedisJSON feels better than manual serialization. Your command says exactly what changed.

Use NX and XX Intentionally

When adding fields, be explicit.

Only set profile.website if it does not exist:

JSON.SET user:42 $.profile.website '"https://www.m4rkyu.com"' NX

Only update plan if it already exists:

JSON.SET user:42 $.plan '"team"' XX

I like this because it turns "oops, I accidentally created the wrong shape" into a failed command instead of silent data drift.

Delete a Field

JSON.DEL user:42 $.profile.website

Delete the whole document with regular Redis:

DEL user:42

When I Would Use RedisJSON

Good fits:

• Session-like documents that change small fields often.
• Feature flags or user settings with nested structure.
• Product/catalog snapshots that need fast reads.
• Cached API responses where you update selected paths.

Weak fits:

• Long-term source-of-truth data with complex relational queries.
• Analytics workloads.
• Huge documents that grow without discipline.
• Anything you need to join across many entities.

RedisJSON is not a relational database replacement. It is a sharp Redis tool for JSON-shaped data.

The Practical Rule

If your app always reads and writes the entire object, plain Redis strings are probably enough.

If your app frequently changes nested fields, increments values, appends to arrays, or reads selected paths, RedisJSON earns its place.

Command Cheat Sheet

JSON.SET user:42 $ '{"name":"Mark"}'
JSON.GET user:42 $
JSON.GET user:42 $.name
JSON.SET user:42 $.plan '"pro"'
JSON.NUMINCRBY user:42 $.usage.revisions 1
JSON.ARRAPPEND user:42 $.profile.skills '"Redis"'
JSON.DEL user:42 $.profile.website
JSON.TYPE user:42 $.profile.skills

That is enough to start. Add search/indexing later only when you have a real query that needs it.