YCSB: workloads A-F, how to run it and its limits

YCSB, the Yahoo! Cloud Serving Benchmark, is an open source Java tool that loads synthetic records into a datastore and then runs a fixed mix of reads, updates, inserts and scans against them while it records throughput and latency per operation. Its six core workloads, A to F, are standard mixes, so the same test can run against Cassandra, MongoDB, Redis, HBase and dozens of other stores through bindings. It measures the datastore on its own, so it says nothing about your application’s real queries or the latency your users see.

We have not run YCSB for this article. The facts come from its GitHub repository, wiki and source code, checked on 31 October 2026, and the judgements are ours.

The mixes come from the files in the workloads directory and the examples from the Core Workloads page (checked on 31 October 2026). Each file ships with only 1,000 records and 1,000 operations, enough to debug a setup and far too few for a benchmark.

What is YCSB, and is it still maintained?

It is a workload generator plus a set of standard workloads for comparing key-value and “cloud serving” stores, released as open source by Yahoo! in 2010 under the Apache 2.0 licence. The last release dates from October 2019, and the code still receives small commits.

The papers page lists the original paper, “Benchmarking Cloud Serving Systems with YCSB” by Cooper, Silberstein, Tam, Ramakrishnan and Sears (ACM SoCC 2010). The 0.17.0 release is dated 6 October 2019 and no later tag exists, while the commit history shows 2026 work such as an option to keep going when an insert fails and a Cloud Spanner change on 20 October (checked on 31 October 2026). Those changes ship only in a build from source, which needs Maven 3.

How do you run a YCSB benchmark?

In two phases that share the same properties: load inserts recordcount records, then run executes operationcount operations from the workload’s mix. You name the binding for your database and pass the workload file with -P.

bin/ycsb load mongodb -s -P workloads/workloada \
  -p recordcount=1000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb
bin/ycsb run mongodb -s -P workloads/workloada \
  -p recordcount=1000000 -p operationcount=5000000 \
  -p mongodb.url=mongodb://db1:27017/ycsb \
  -threads 32 -target 20000

The Running a Workload page covers the details that trip people up (checked on 31 October 2026). The client never creates tables, so you first map usertable to whatever your store needs, such as a table in MySQL or a keyspace in Cassandra. Later -P files override earlier ones, and -p overrides them all. The run phase needs the same recordcount as the load, because it picks keys from the full dataset. -s prints a status line every 10 seconds. Because D and E insert records, the Core Workloads page suggests loading once with workload A’s file, running A, B, C, F and D, then deleting the data and reloading for E.

What do -threads and -target control?

-threads sets how many client threads send operations (one by default), and -target caps the total operations per second. Without a target each thread sends its next operation as soon as the last one returns, so a slower database simply receives less load.

That is a closed loop, and our article on the open vs closed workload model explains what it hides. The wiki’s example of 10 threads and a target of 100 operations per second holds only while average latency stays under 100 ms; with too few threads the achieved rate falls below the target. That is Little’s law at work: threads divided by average latency caps the throughput. Running several targets and noting the latency at each gives you the curve from our guide to throughput vs latency.

How do you read YCSB output?

At the end of each phase the client prints an [OVERALL] block with run time and throughput, then one block per operation type with the count, average, minimum, maximum and percentile latencies, plus a count per return code.

These field names come from the 0.17.0 source code; the values are placeholders:

[OVERALL], RunTime(ms), <total>
[OVERALL], Throughput(ops/sec), <rate>
[READ], Operations, <count>
[READ], AverageLatency(us), <value>
[READ], 95thPercentileLatency(us), <value>
[READ], 99thPercentileLatency(us), <value>
[READ], Return=OK, <count>

The wiki’s sample output shows milliseconds, but the default HdrHistogram measurement in both 0.17.0 and the current source reports microseconds, (us). The Core Properties page and release 0.17.0 set the default percentiles to 95 and 99, changeable with hdrhistogram.percentiles; since April 2025 the master branch adds 50, so a source build also prints 50thPercentileLatency(us) (checked on 31 October 2026). The README points you at P99 and beyond, warns that percentiles cannot be averaged, and suggests saving HDR histogram files with hdrhistogram.fileoutput=true and merging them when several clients run.

Does YCSB account for coordinated omission?

Only when you ask for it, and only with -target set. By default each latency is timed from the moment the operation was actually sent, so a stall that delays the operations queued behind it barely shows.

The measurements source has a measurement.interval property that takes op (the default), intended or both (checked on 31 October 2026). Under a target, each thread records the scheduled start of every operation; intended times latency from that point, and both adds Intended- blocks such as [Intended-READ] next to the usual ones. The wiki does not list measurement.interval, so check the source you build. Our guide to coordinated omission explains why the scheduled start gives the honest number.

Which databases can YCSB benchmark?

Any store with a binding. The build file on the master branch lists 46 binding modules, among them Cassandra, MongoDB, Redis, HBase, DynamoDB, Cloud Spanner, RocksDB and a generic JDBC binding.

The list is in the pom.xml, and each binding directory has its own README with connection properties, such as mongodb.url for the MongoDB binding (checked on 31 October 2026). The Running a Workload page says one client machine suits clusters of about 10 machines; beyond that you start several clients, and the Running a Workload in Parallel page splits the load between them with insertstart and insertcount.

When is YCSB the wrong tool?

When your question is about your application. The core workload writes synthetic records, 10 fields with a length of 100 each by default, through simple key operations, so it cannot show how your own queries, indexes or API code behave under load.

• For relational OLTP, pgbench runs a TPC-B-like script against PostgreSQL and accepts your own scripts, and sysbench bundles OLTP-style Lua benchmarks (both checked on 31 October 2026).
• For latency as users see it, load the HTTP or API layer in front of the datastore. LoadFocus, which publishes this site, runs JMeter test plans and k6 scripts from 25 cloud regions against web and API endpoints. It does not run YCSB.

FAQ

What are the YCSB core workloads? Six standard mixes: A is 50% reads and 50% updates, B is 95% reads, C is read only, D favours the most recently inserted records, E runs short scans, and F does read-modify-write.

What is the difference between ycsb load and ycsb run? The load phase inserts the number of records set by recordcount. The run phase then executes operationcount operations from the workload’s mix against those records and reports throughput and latency.

Is YCSB still maintained? The last release, 0.17.0, came out on 6 October 2019. The repository still receives occasional commits, the most recent on 20 October 2026, so newer fixes require a build from source.

Can LoadFocus run YCSB benchmarks? No. LoadFocus does not run YCSB. It runs JMeter test plans and k6 scripts aimed at web and API endpoints, the layer in front of the datastore.

Related reading

• Coordinated omission: what it is and how to avoid it
• Tail latency: what it is and how to measure it
• Open vs closed workload model: which one should you use?
• Little’s law in load testing: size and check your tests
• Throughput vs latency: how they interact under load
• pgbench: how to benchmark and load test PostgreSQL
• How to use sysbench for CPU, disk and MySQL benchmarks
• redis-benchmark: how to use it and read its numbers
• TPC-H: what the benchmark measures and how to run it

The technical claims in this article have not been independently reviewed.