Performance Benchmark of RedisJSON vs MongoDB and ElasticSearch

Overview

Recent official tests released a performance report for RedisJSON (RediSearch) that demonstrates it vastly outperforms other NoSQL solutions. Key conclusions are:

For isolated writes, RedisJSON is 5.4× faster than MongoDB and over 200× faster than ElasticSearch.

For isolated reads, RedisJSON is 12.7× faster than MongoDB and over 500× faster than ElasticSearch.

In mixed‑workload scenarios, real‑time updates do not degrade RedisJSON's search or read performance, whereas ElasticSearch suffers.

RedisJSON supports roughly 50× more operations per second than MongoDB and 7× more than ElasticSearch.

RedisJSON latency is about 90× lower than MongoDB and 23.7× lower than ElasticSearch.

RedisJSON also maintains far more stable latency at higher percentiles and can sustain higher overall throughput as write ratios increase, unlike ElasticSearch which sees throughput drop.

Query Engine

The RedisJSON and RediSearch development teams focus heavily on performance, providing analysis tools and detectors for developers.

Version 2.2 improves loading and query performance by 1.7× over version 2.0, along with better throughput and data‑loading latency.

2.1 Loading Optimizations

The following two charts show results of the New York City taxi benchmark.

Each new RedisJSON release shows a substantial performance improvement.

2.2 Full‑Text Search Optimizations

To evaluate search performance, 5.9 million Wikipedia abstracts were indexed and a full‑text query panel was run. The results are shown in the following images.

Moving from v2.0 to v2.2 yields large improvements in write, read, and search latency, increasing overall achievable throughput for Search and JSON.

Comparison with Other Frameworks

RedisJSON was benchmarked against MongoDB and ElasticSearch across document storage, on‑premise availability, cloud availability, professional support, scalability, and performance.

The YCSB benchmark suite was used to generate realistic workloads, measuring latency and throughput until saturation. In addition to standard CRUD operations, a two‑character search operation was added to help developers and DevOps engineers choose the best search engine for their use case.

3.1 Benchmark Setup

The test environment included:

MongoDB v5.0.3

ElasticSearch 7.15

RedisJSON (RediSearch 2.2 + RedisJSON 2.0)

All three solutions ran on identical AWS m5d.8xlarge VMs with local SSDs, using a four‑VM cluster (one client + three database servers) tightly packed in a single availability zone to ensure low‑latency networking.

Deployments were three‑node clusters:

MongoDB 5.0.3 : a three‑member replica set with a text index for string search.

ElasticSearch 7.15 : 15 shards, query cache enabled, RAID‑0 on two NVMe SSDs.

RedisJSON* : RediSearch 2.2 + RedisJSON 2.0 on an OSS Redis Cluster v6.2.6 with 27 shards evenly distributed across three nodes.

Additional network, memory, CPU, and I/O benchmarks were run to understand underlying VM characteristics. Network latency stayed well below 100 µs (p99) throughout.

3.2 100% Write Benchmark

RedisJSON* ingest speed was 8.8× faster than ElasticSearch and 1.8× faster than MongoDB, while maintaining sub‑millisecond latency per operation; 99% of Redis requests completed in under 1.5 ms.

RedisJSON* uniquely updates its index on every write, providing immediate searchability. ElasticSearch buffers writes and refreshes the index periodically (near‑real‑time), incurring higher latency.

Overall, RedisJSON* is 5.4× faster than MongoDB and over 200× faster than ElasticSearch for isolated writes.

3.3 100% Read Benchmark

RedisJSON* reads were 15.8× faster than ElasticSearch and 2.8× faster than MongoDB, with sub‑millisecond latency across the board.

Combined latency and throughput improvements make RedisJSON* 12.7× faster than MongoDB and over 500× faster than ElasticSearch for isolated reads.

3.4 Mixed Read/Write/Search Benchmark

Real‑world workloads are typically a mix of reads, writes, and searches. A 65 % search / 35 % read scenario was used as a baseline; both RedisJSON* and ElasticSearch achieved similar throughput at this mix.

Adding 10 % writes to each variant showed that RedisJSON* maintains throughput while ElasticSearch’s throughput degrades sharply as write proportion increases.

Increasing the write ratio harms ElasticSearch performance dramatically, whereas RedisJSON* continues to handle updates without affecting read or search latency, resulting in higher overall throughput.

ElasticSearch ops/sec drop from ~10 k at 0 % updates to a fifth of that at 50 % updates. MongoDB’s maximum throughput is 424 ops/sec, while RedisJSON* reaches about 16 k ops/sec.

Overall, RedisJSON* delivers 50.8× more ops/sec than MongoDB and 7× more than ElasticSearch in mixed workloads, with latency reductions of up to 91× versus MongoDB and 23.7× versus ElasticSearch.

3.5 Full Latency Analysis

A comprehensive latency analysis under sustainable load confirms RedisJSON* as the most stable solution across all percentile ranges, with p99 latency under 2.61 ms compared to 10.28 ms for ElasticSearch.

In read and update tests, RedisJSON* consistently shows the lowest latency, followed by MongoDB and then ElasticSearch.

Both MongoDB and RedisJSON* keep sub‑millisecond latency even at p99 for writes, while ElasticSearch exhibits high tail latency (>10 ms), likely due to GC pauses.

3.5.1 MongoDB vs ElasticSearch vs RedisJSON* Latency

When focusing on search latency, MongoDB outperforms the other two, but RedisJSON* remains far more stable than ElasticSearch, whose p99 reaches 10.49 ms versus RedisJSON*’s 0.23 ms.

3.5.2 ElasticSearch vs RedisJSON* Latency

At a sustained 6 k ops/sec load, RedisJSON* maintains p99 read latency of 3 ms versus ElasticSearch’s 162 ms. For updates, RedisJSON* holds p99 at 3 ms while ElasticSearch spikes to 167 ms.

Search operations start with single‑digit p50 latency (RedisJSON* p50 = 1.13 ms, ElasticSearch p50 = 2.79 ms). ElasticSearch’s latency grows sharply at higher percentiles due to GC and cache misses, while RedisJSON* keeps p99 below 33 ms.

PS: If you found this sharing useful, feel free to like and watch.