Skip to main content

Stress-test your database, not your load generator.

Stroppy is a single Go binary that runs TPC-B, TPC-C, TPC-H and TPC-DS against PostgreSQL, MySQL, Picodata and YDB. We kept catching benchmarks that were really measuring the client, so Stroppy can tell you where its own limit is before you start blaming the database.

curl -fsSL https://github.com/stroppy-io/stroppy/releases/latest/download/stroppy_linux_amd64.tar.gz | tar -xz
sudo install stroppy /usr/local/bin/

It’s one file, about 40 MB, and the archive has nothing else in it. Docker and building from source are covered in the introduction.

One command in, a summary out

All of it ships in the one binary, since version 6 dropped k6 and TypeScript and there’s nothing left to install next to it. Hover a note to see which part of the run it’s about.

~/bench
$ stroppy run tpcb/tx -d pg -D url=postgres://localhost/bench --executor constant-vus --vus 8 --duration 30s
19:08:49.103  INFO  End of 'create_schema' step (took 24ms)
19:08:49.236  INFO  End of 'load_data' step (took 132ms)
19:08:49.553  INFO  End of 'analyze' step (took 262ms)

=== bench summary ===
  transactions_total                       5603.000
  failed_iterations_total                  0.000
  tx_total_duration
    count=5603 avg=42.767 p(50)~=50.000 p(90)~=100.000 p(95)~=100.000 p(99)~=250.000
  tx_commits_total                         5603.000
  tps                                      186.530
  queries_per_second                       932.648
  measurement_seconds                      30.038
Real output from Stroppy 6.1.1 against PostgreSQL 17 in Docker, trimmed to the lines the notes talk about.

What you ask for

What you get back

How fast the client is, and why it matters

Every number a load generator reports includes the load generator. If the client is slow, the database waits and you end up measuring the tool. stroppy baseline shows how much room it leaves on your machine.

go-tpc → StroppyTPC-C on OrioleDB, one hour, 1000 warehouses, 100 VUs, Stroppy 5.7.2. How we found it
× go-tpc
go-tpc → tpcc/procs: 6,399 transactions per second before, 15,791 after, 2.5 times as many.
v5 on k6 → v6Medians of five runs on one AMD EPYC Genoa VM. Big on the noop driver, small on a real database, which is how it should be. Why we dropped k6
× v5
TPC-B ceiling, 1 VU: 4,368 transactions per second before, 145,524 after, 33.3 times as many.
TPC-B ceiling, 24 VUs: 38,694 transactions per second before, 517,627 after, 13.4 times as many.
TPC-C on PostgreSQL, 1 VU: 202 transactions per second before, 290 after, 1.4 times as many.
TPC-C on PostgreSQL, 16 VUs: 2,892 transactions per second before, 3,368 after, 1.2 times as many.
Database → Stroppy ceilingSame VM, 16 VUs. Different workloads; the gap is the room the client leaves.
× PostgreSQL
PostgreSQL TPC-C → noop TPC-B: 3,368 transactions per second before, 500,772 after, 148.7 times as many.

Don’t feel like setting up the machines?

Stroppy Cloud does that part. You pick a database and a workload; it brings up the stand in your cloud, runs the test and gives you a report with queries per second, latency and the moment errors began. Run it again next week and the two sit side by side.

Open Stroppy Cloud