SYSTEM Cited by 1 source

sysbench¶

What it is¶

sysbench (akopytov/sysbench) is an open-source scriptable benchmark tool for evaluating system and database performance, commonly used to benchmark MySQL and Postgres under OLTP-shaped workloads. Originally written for MySQL regression testing, it now supports Lua-scripted workloads driven by a multi-threaded load generator.

Canonical workloads¶

sysbench ships with Lua scripts implementing several synthetic OLTP shapes:

oltp_read_only — point selects + simple range scans + range aggregates; no writes.
oltp_write_only — inserts, updates, deletes; no reads.
oltp_read_write — a fixed mix of reads and writes per transaction.
oltp_point_select — pure primary-key lookups.
oltp_update_index / oltp_update_non_index — isolate index vs heap update paths.

Key knobs¶

--tables=N — create N tables.
--table_size=N (also exposed as SCALE) — rows per table.
--threads=N — concurrent connections.
--time=N — run duration in seconds.
--range_size=N — number of rows touched by range-scan queries (100 = small-range; 10,000 = large-range).
--report-interval=N — interval QPS prints.

Why it matters on the wiki¶

sysbench is the most widely cited OLTP benchmark tool in production database blog posts. Vendor benchmarks (PlanetScale, AWS Aurora, Percona, MongoDB, TiDB) routinely cite sysbench QPS deltas as headline numbers.

Its limitations for representativeness:

Uniform random key distribution — real OLTP workloads have hot keys and skew; sysbench doesn't model this.
Short transactions — real workloads mix short point lookups with long analytical queries.
No secondary workload interference — no concurrent VACUUM / backup / replication traffic.
Write patterns are synthetic — real writes cluster by business process, not uniformly across the keyspace.

For database-version comparison (e.g., Postgres 17 vs 18) these limitations are symmetric across the comparison — both versions see the same workload shape — so sysbench deltas are credible for version-to-version comparison even if not representative of any specific real workload.

Seen in¶

— canonical wiki introduction. Ben Dicken runs 96 oltp_read_only configurations (4 Postgres configs × 4 instance types × 2 --range_size values × 3 concurrency levels, 5 min each) across three EBS-backed EC2 instances and one local-NVMe i7i to compare Postgres 17 vs Postgres 18's io_method variants.
sources/2026-04-21-planetscale-benchmarking-postgres — methodology disclosure for PlanetScale's multi-vendor Postgres comparison programme. Two sysbench-family workloads drive the non-latency benchmarks: Percona's sysbench-tpcc scripts at TABLES=20, SCALE=250 produce a ~500 GB TPCC-like database, and sysbench oltp_read_only runs at 300 GB for top performers. Both workloads are driven by Telescope, PlanetScale's internal benchmarking harness. Reproduction instructions at /benchmarks/instructions/tpcc500g and /benchmarks/instructions/oltp300g let third parties rerun the same configs — canonical wiki instance of sysbench underpinning a reproducibly- published vendor benchmark.
— Jonah Berquist (PlanetScale, 2022-09-01) uses the Percona sysbench-tpcc port (not stock sysbench's oltp_* workloads) to drive a Vitess-on-MySQL cluster to >1M QPS sustained on 40 shards. Canonical wiki datapoints: 16 shards = 420k QPS, 32 shards = 840k QPS, 40 shards = 1M+ QPS. The scan methodology — sweep thread counts (up to 4096) at each shard count — reveals both per-configuration saturation (QPS-per-thread derivative goes negative) and linear-with-shard-count scaling across configurations. Author's caveat: "We weren't aiming for a rigorous academic benchmark here, but we wanted to use a well- known and realistic workload" — sysbench-tpcc fills the OLTP- shaped but non-academic middle tier between stock sysbench's synthetic oltp_read_write and a full industry benchmark like HammerDB's TPC-C. Pairs with the Postgres-benchmarking post above which uses the same sysbench-tpcc at TABLES=20, SCALE=250 (~500 GB) for cross-vendor Postgres comparison.
— sibling benchmark framing. Liz van Dijk (PlanetScale, 2022-09-08) introduces TAOBench as a social-graph-shaped complement to sysbench-tpcc — addressing the gap that "The TPC-C benchmark has had a very long life, and has remained remarkably relevant until this day, but there are scenarios it doesn't cover. Audrey Cheng and her team at University of California, Berkeley identified a real gap when it comes to available synthetic benchmarks for a more recent, but highly pervasive workload type: social media networks." The two benchmarks are intentionally complementary in PlanetScale's published benchmarking: sysbench-tpcc for OLTP-shaped shard-linear scaling demonstration; TAOBench for social-graph-shaped substrate maturity + viral-content stress disclosure. Both appear in the same 2022 benchmarking push from PlanetScale's Tech Solutions team. The key substrate-axis difference: sysbench-tpcc has no hot rows by construction (access patterns shard-key-aligned); TAOBench's objects + edges schema explicitly stresses hot-row / thundering-herd behaviour as a workload-design target.