Skip to main content

Sysbench benchmark results

These are Sysbench results for MongoDB Enterprise across compute flavors, published so you can size a cluster before provisioning it.

warning

These figures are reference data from a synthetic workload, not a performance guarantee. Your throughput will differ. Test with your own workload before committing to a production configuration.

What was measured

The benchmark evaluates OLTP read/write performance, shows how throughput scales with CPU and memory, and gives a basis for choosing an instance size.

MetricMeaning
Sysbench ReadTotal read queries executed during the test
Sysbench WriteTotal write queries executed during the test
QPSAverage queries processed per second
TPSAverage completed transactions per second

Higher QPS and TPS mean higher throughput under the tested workload.

Test environment

ParameterValue
Benchmark toolSysbench (OLTP Read/Write)
Number of documents1,000,000
Number of operations1,000,000
Workload typeRead/Write
Thread countVaries per flavor — see results
MongoDB versionMongoDB Enterprise v8.0.20-ent
IOPS6,000

Results

Flavor (vCPU/RAM)ThreadsSysbench ReadSysbench WriteQPSTPS
2C4G8500,310499,6904,083.954,083.95
2C8G8500,652499,3485,120.565,120.56
4C8G16499,868500,1329,007.799,007.79
8C16G32501,398498,60217,666.6017,666.66
8C32G64500,420499,52921,993.4921,993.49
16C32G64499,522500,47831,626.5531,626.55
16C64G128500,086499,91434,621.2434,621.24

Reading the numbers

Throughput rises with CPU and memory, but not linearly. Going from 2C4G to 2C8G (doubling RAM alone) adds about 25% QPS, while 4C8G to 8C16G roughly doubles it. Gains flatten at the higher configurations as other limits take over.

Your actual performance depends on:

  • Application workload characteristics
  • Schema design and indexing
  • Read/write ratio
  • Storage and network configuration

Note the test ran at 6,000 IOPS. At a lower storage policy, I/O becomes the bottleneck and additional vCPU will not deliver these numbers.

Next steps