A benchmark result describes a workload and environment, not just a database. This older pgbench note recorded initialization, a ten-client run, and a sixty-second mixed-script run.
The recorded commands
pgbench -i -p 5432 -d defaultdb -U admin
pgbench -p 5432 -d defaultdb -U admin -c 10
pgbench -p 5432 -d defaultdb -U admin -c 50 -T 60 -S -n
nano /tmp/bench.sql
CREATE TABLE IF NOT EXISTS test_bench (id int8, data varchar);
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
pgbench -p 5432 -d defaultdb -U admin -c 50 -T 60 -S -n -f /tmp/bench.sqlThis listing mixes shell commands with the SQL intended for /tmp/bench.sql. The initialization creates benchmark tables, and the custom script contains writes; it is not a read-only diagnostic for an arbitrary database.
Results in the original screenshots
| Recorded run | Transactions | Average latency | TPS including connection establishment |
|---|---|---|---|
| 10 clients, built-in TPC-B-like workload | 100 | 564.419 ms | 17.717334 |
| 50 clients, 60 seconds, mixed scripts | 18,403 | 164.041 ms | 304.801481 |
The preparation screenshot showed scale-factor-one initialization. In the mixed run, the built-in select-only script handled 9,127 transactions and the custom script handled 9,276.
These results are transcribed from the old screenshots, not newly measured. They use different workloads and do not establish that adding clients caused a performance improvement. Hardware, database configuration, dataset, and repeat-run evidence are not recorded sufficiently for a reproducible comparison.