The essentials
pgbench (official PostgreSQL tool, workload close to TPC-B) and sysbench-tpcc (TPC-C workload more representative of a real transactional load) both run directly against the standard Postgres 16 connection string of your Aurabase project — no proprietary API to bypass. This tutorial shows the actual orders, and where what a GST figure can legitimately prove ends.
pgbench for simplicity, sysbench-tpcc for realism
pgbench is distributed with PostgreSQL itself: no separate installation on the client if you already have Postgres client tools. Its default workload reproduces a load close to the historical TPC-B benchmark — simple, quick to launch, useful for a first signal.
sysbench is a more general benchmark tool, with a sysbench-tpcc plugin that replicates the TPC-C workload — a mix of transactions representative of a real OLTP application (orders, payments, inventory), closer to what your Aurabase backend handles in production than the generic pgbench workload.
Retrieve the connection string and create a dedicated test base
1
Retrieve the connection string from the Aurabase dashboard
Database section of your project, standard postgresql://user:password@host:5432/dbnameformat.
2
Create a separate test base, never your production base
psql "$AURABASE_CONN" -c "CREATE DATABASE bench_test;"
pgbench and sysbench-tpcc create, populate and modify tables. Always use a dedicated base, never a scheme that serves real traffic.
Initialize and launch a first run
1
Initialize the dataset
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = scale factor (10 × 100,000 rows in pgbench_accounts)
2
Run a 60 second run, 10 competing clients
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = concurrent clients · -j = threads · -T = duration in seconds · -P = report every 5s
3
Read the result
pgbench displays a tps (transactions per second) at the end of the run, with and without the connection time. Note the scale factor, number of clients, and duration per run — without these three parameters, the number alone means nothing.
A more representative transactional workload
1
Install sysbench and the tpcc plugin
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # follow the README of the repository for compiling the plugin
2
Prepare the TPC-C dataset
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 prepare
3
Start the run
./tpcc.lua --pgsql-host=host --pgsql-user=user --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 run
A sysbench-tpcc tuning guide dedicated to PostgreSQL was published by Percona in May 2026 — useful for tuning shared_buffers and work_mem before running a representative run.
What a GST figure alone doesn't prove
The tps depends on the scale factor, the number of concurrent clients, the underlying hardware and the Postgres settings active at the time of the run. Two time figures obtained with different parameters are not comparable, even on the same database.
For your result to serve as a reproducible reference, systematically document: Postgres version, scale factor, number of clients/threads, run duration, and the effective postgresql.conf configuration. See our full benchmark methodology for the protocol we apply before publishing a figure.
Tuning Postgres before restarting a run
A benchmark run often reveals a bottleneck before any adjustment — saturated connections, lagging autovacuum, missing index. Our Postgres tuning checklist in production and our article on max_connections sizing cover the settings to check before restarting a run.