How the databases were tested

This report compares YCSB benchmark results for five NoSQL databases: Redis, MongoDB, Couchbase, Yugabyte, and BangDB. The tests used the latest available versions of each database, running under optimized conditions as recommended by each vendor. All benchmarks used the standard six YCSB core workloads, with 10 million records per test on a 16-core machine with 32GB RAM.

  • Redis Server: 5.07, x86_64
  • MongoDB server: 4.4.2, x86_64
  • YugabyteDB: 2.5.0, x86_64
  • Couchbase2: 7.0 Beta, x86_64
  • BangDB server: 2.0.0, x86_64

Each workload ran in two stages: first a load phase to populate the database, then the benchmark run. Every test started with a clean database to keep results comparable. Workload definitions follow the standard YCSB core workloads on the YCSB GitHub wiki.

Notably, load performance was consistent across all databases for every test, which is expected since this phase primarily measures write throughput. The run phase is where differences in handling mixed access patterns emerge.

Workload A: Update heavy

This mix is 50% reads and 50% writes, modeling a session store that records recent user actions. Throughput and completion time for the 10M record run are shown below.

MongoDB showed remarkably low update latency relative to the other databases, although its read latency was comparatively high. The throughput and time-to-complete figures reflect these tradeoffs across the other systems.

Workload B: Read mostly

A 95/5 read/write split represents workloads like photo tagging, where most operations fetch tags but occasionally add new ones.

The latency table reveals that Yugabyte's 99th percentile read latency far exceeded the other databases. Lower values are better here, and Yugabyte's gap was consistent across the percentile distribution.

Workload C: Read only

This workload is entirely reads, simulating a user profile cache that is populated elsewhere. Since no writes occur, only read latency figures are reported.

Yugabyte again stood out with significantly higher latency compared to the rest of the field.

Workload D: Read latest

New records are inserted continuously, but reads concentrate on the most recently added data — typical of user status feeds.

In this scenario, Redis and Yugabyte both registered higher latencies. Yugabyte performed poorly for both insert and read operations, with consistently elevated latency numbers.

Workload E: Short ranges

Instead of point lookups, clients scan short ranges of records, as in threaded conversation views that fetch all posts in a thread. This scan-heavy pattern lowers throughput across the board.

Redis was the slowest here, which its latency table reinforces. In contrast, Yugabyte delivered its strongest performance of all six workloads in this scan-oriented test.

Workload F: Read-modify-write

Clients read a record, alter it, and write it back — the classic pattern for updating user profile records based on activity.

Yugabyte exhibited the highest latency for both update and read-modify-write operations, especially at the 99th percentile. MongoDB finished last overall due to very high read latency in this workload.

Practical takeaways

The YCSB framework provides a common baseline despite each database being engineered around different design goals and access patterns. These numbers should help developers compare systems in a consistent environment before choosing one for a specific use case. All the databases tested are freely downloadable, so reproducing these runs locally is straightforward. The standard YCSB workloads can also be extended or modified to cover scenario-specific requirements.