Throughput, reported as transactions per second (TPS), measures how much completed database work a PostgreSQL server delivers during a benchmark. It is useful for comparing a fixed workload across configurations, but it is not a sufficient health signal on its own: the same TPS can hide radically different latency and overload. section 6.2 section 6.3
A tempting mistake is to increase memory settings or connection counts and treat any TPS change as proof of improvement. In a 100-client pgbench run, increasing shared_buffers and work_mem produced roughly the same result—about 1,082 TPS before tuning and 1,063 afterward—while a 1,000-client stress run fell to about 148 TPS before hanging. More allocated memory and more concurrency can make the system less stable rather than more productive. section 6.2
Read TPS with latency and failures
A 2,000-client run completed about 352 TPS, but average latency was about 5.5 seconds. Reducing client counts raised TPS into a broad plateau while latency steadily improved; at 32 clients, latency was about 56 ms. The plateau did not mean every concurrency level was equally healthy: overloaded runs preserved throughput by making requests wait longer, while 16 clients supplied too little work to use the server fully. section 6.3
Use TPS as a controlled operational comparison:
- Keep the workload, duration, client host, and benchmark settings comparable between runs; run the benchmark from another host so benchmark work does not overload the database server. section 6.2
- Pair TPS with average latency, latency variation, and failed transactions; a stable TPS value can conceal unacceptable waiting time. section 6.2 section 6.3
- Vary client counts to locate both underutilization and overload rather than selecting a connection limit from TPS alone. section 6.3
- Treat severe TPS collapse, hangs, and memory-pressure logs as safety failures, not merely poor benchmark scores. section 6.2
Table 6.1 Test results showing TPS and latency with various numbers of clients
|
Number of clients
|
TPS
|
Latency average
|
|---|---|---|
|
2,000
|
352.1
|
5,535.267 ms
|
|
1,500
|
506.8
|
2,869.986 ms
|
|
1,000
|
586.1
|
1,694.616 ms
|
|
500
|
628.4
|
794.688 ms
|
|
250
|
635.7
|
392.554 ms
|
|
125
|
556.9
|
224.411 ms
|
|
63
|
613.0
|
102.758 ms
|
|
32
|
572.3
|
55.907 ms
|
|
16
|
301.8
|
53.009 ms
|
This client-count sweep makes the central comparison visible: TPS peaks and plateaus across several loads, whereas latency reveals when concurrency is still overloading the server. section 6.3
