pgbench Command Generator

Build correct pgbench command lines for PostgreSQL load testing without memorising the flags. Choose a scale factor, client and thread counts, run duration and query protocol, then copy the initialization and benchmark commands. Everything runs in your browser — no connection is made and nothing is uploaded.

Connection

HostPortUserDatabaseShow PGPASSWORD line

Initialization

Scale factor (-s)FillfactorDrop and rebuild (-I dtgvp)Foreign keysUnlogged tables

Workload

ScriptProtocol

Clients (-c)Threads (-j)Duration seconds (-T)Fixed transaction count instead of duration

Progress seconds (-P)Target rate (-R)Latency limit ms (-L)Reconnect per transaction (-C)Per-statement latency (-r)

pgbench commands

# 1. Create the benchmark database (run once)
createdb -h localhost -U postgres benchdb

# 2. Initialize pgbench tables at scale factor 100 (~1.50 GB of pgbench_accounts data)
pgbench -h localhost -U postgres -i -I dtgvp -s 100 benchdb

# 3. Run the benchmark
pgbench -h localhost -U postgres -c 16 -j 4 -T 300 -M prepared -P 10 -r benchdb

Commands are assembled entirely in your browser. No connection is opened, no credentials are stored and nothing is uploaded. The init step drops and recreates the pgbench tables, so never point it at a production database.

Do more than pgbench command generator — meet Chat2DB

Chat2DB is an AI-powered SQL client for Windows, macOS and Linux. Write SQL in natural language, format and optimize queries automatically, and manage MySQL, PostgreSQL, Oracle and 20+ other databases in one workspace.

Flag reference

Flag	What it does
-i	Initialize the pgbench tables. Destroys and recreates them.
-I dtgvp	Init steps: drop, create tables, generate data, vacuum, create primary keys.
-s N	Scale factor. 100,000 rows in pgbench_accounts per unit, roughly 15 MB each.
-c N	Number of concurrent clients (database sessions).
-j N	Number of pgbench worker threads. Must be ≤ the client count.
-T N	Run for N seconds.
-t N	Run N transactions per client instead of a fixed duration.
-S	Read-only workload: a single SELECT per transaction.
-f file	Run a custom script instead of the built-in TPC-B workload.
-M mode	Query protocol: simple, extended, or prepared.
-P N	Print a progress line every N seconds.
-R rate	Throttle to a target transactions-per-second rate.
-L ms	Count transactions slower than this limit as late.
-C	Open a new connection for every transaction.
-r	Report per-statement latency averages.

How to use

Fill in the connection details and the scale factor you want pgbench to initialize.
Pick a workload — built-in TPC-B, read-only SELECT, or a custom script — and set clients, threads and duration.
Copy the generated commands into your shell, run the init step once, then run the benchmark.

Frequently asked questions

What scale factor should I use for pgbench?

The scale factor sets how much data pgbench creates: pgbench_accounts gets 100,000 rows per unit of scale, which works out to roughly 15 MB per unit. Two rules matter. First, pick a scale factor at least as large as your client count, because pgbench_branches has only one row per unit of scale and the default TPC-B script updates it on every transaction — a small scale turns the benchmark into a lock contention test. Second, decide whether you want to measure cached or disk-bound behaviour: a dataset that fits comfortably in shared_buffers and the OS page cache measures CPU and lock throughput, while a dataset several times larger than RAM measures your storage.

What is the difference between -c, -j and -T?

-c is the number of simulated clients (concurrent database sessions), -j is the number of operating system threads pgbench uses to drive those clients, and -T is the run duration in seconds. The thread count must not exceed the client count. On a multi-core machine a single pgbench thread can become the bottleneck before PostgreSQL does, so raise -j until pgbench itself is no longer saturating a core — a common starting point is one thread per two to four clients, with clients divisible by threads so the load spreads evenly. Use -t instead of -T if you want a fixed transaction count per client rather than a fixed wall-clock duration.

Why do my pgbench numbers change between runs?

Short runs are dominated by cache warm-up, autovacuum activity and checkpoint timing, so the first run against a freshly initialized database is almost always faster or slower than steady state. Run for at least five minutes (-T 300), discard the first run, and use -P 10 to watch whether throughput is still drifting. Checkpoints in particular produce periodic dips; if you see them, check log_checkpoints output and tune checkpoint_timeout and max_wal_size before comparing results. Also make sure nothing else is running on the machine, and run pgbench from a separate host when you are testing a server that is already CPU-bound. To inspect the tables and query plans pgbench is exercising, Chat2DB (https://chat2db.ai/download) connects to the same PostgreSQL instance and shows EXPLAIN output side by side.