I use YCSB as a starting point, not a verdict. It is helpful when the workload resembles the decision in front of me, but I still recommend measuring the real application path before choosing a store.
A benchmark needs a workload story
I connect the benchmark to the workload it is supposed to represent.
A read heavy catalog, a write heavy event store, and a mixed user profile service stress different parts of a database. YCSB lets teams run named workloads so they can compare latency and throughput under the same conditions.
Store comparison example
I prefer this kind of example because it forces the design to answer real questions about latency, recovery, and handoffs.
A team compares two key value stores before moving session data. They run a read heavy workload, then a balanced read write workload, and compare p95 latency under the same record count.
Workload config example
This is the part where theory has to meet the actual work people do every day.
Run the same workload against each store before comparing latency:
./bin/ycsb load jdbc -P workloads/workloadb -p recordcount=100000
./bin/ycsb run jdbc -P workloads/workloadb -p operationcount=50000The first command loads data and the second runs workload B against the same database. Separating load from run keeps the benchmark result easier to compare.
Sequence diagram: compare data stores with one workload
The benchmark is useful because both stores receive the same workload and the team knows what pattern it represents.
The measurement choice
- Choose workloads that match real access patterns.
- Compare tail latency, not only average latency.
- Validate benchmark findings with application level tracing.