SYSTEM Cited by 2 sources

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¶

sources/2025-10-14-planetscale-benchmarking-postgres-17-vs-18 — 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.