Subject: Low TPS

From: Raj <[email-masked]>
Date: Thu, 4 Jun 2026 09:41:29 +0530

Hi all,

If the application teams they are able achive only 60TPS and this is not
expected. They are calculating based on total suçcess requests/minutes we
ran load test*60.

---

From: Frank Heikens <[email-masked]>
Date: Thu, 4 Jun 2026 04:18:12 +0000

Hi,

At the moment there isn’t enough information to determine whether PostgreSQL is the bottleneck.

A throughput of 60 TPS by itself does not tell us much. The limitation could be in the application, connection pool, network, database, storage subsystem, external services, or even the load test setup itself.

Could you provide some additional information?

* PostgreSQL version
* Deployment type (bare metal, VM, AWS RDS, Azure, etc.)
* Number of application instances
* Connection pool being used (PgBouncer, HikariCP, etc.)
* Average response time during the test
* Number of active database connections
* CPU, memory, and disk utilization during the test
* Top queries from pg_stat_statements
* Wait events observed during the test
* Whether the workload is read-heavy, write-heavy, or mixed

From the database side, I would monitor at least:

* CPU utilization
* Memory utilization
* I/O throughput and latency
* Active sessions (pg_stat_activity)
* Wait events
* Transactions per second
* Cache hit ratio
* Checkpoint activity
* WAL generation rate
* Query execution times (pg_stat_statements)
* Lock contention
* Replication lag (if applicable)

Without these metrics, it is impossible to determine whether PostgreSQL is actually limiting throughput or whether the bottleneck is elsewhere.

Could you share the above information and some monitoring graphs from the load test?

Frank

> On Jun 3, 2026, at 9:11 PM, Raj <[email-masked]> wrote:
> 
> 
> Hi all,
> 
> If the application teams they are able achive only 60TPS and this is not expected. They are calculating based on total suçcess requests/minutes we ran load test*60.
> 
> From Database side what we can do and during.load test what are all.the metric we need to monitor from our side. Vcpu 32, 128GB RAM

---

From: Raj <[email-masked]>
Date: Fri, 5 Jun 2026 09:17:53 +0530

Postgres 17.9
VM
Pgnouncer
Mixed workload

Disk utlization means - IO or pgdats is increasing?

On Thu, 4 Jun 2026, 09:48 Frank Heikens, <[email-masked]> wrote:

> A throughput of 60 TPS by itself does not tell us much. The limitation
> could be in the application, connection pool, network, database, storage
> subsystem, external services, or even the load test setup itself.
>
> Without these metrics, it is impossible to determine whether PostgreSQL is
> actually limiting throughput or whether the bottleneck is elsewhere.
>
> > From Database side what we can do and during.load test what are all.the
> metric we need to monitor from our side. Vcpu 32, 128GB RAM
>

---

From: Raj <[email-masked]>
Date: Fri, 5 Jun 2026 10:14:37 +0530

Cache hir ratio is 74. When I checked there were only couple of big
partition tables have less cache hit ratio

On Fri, 5 Jun 2026, 09:17 Raj, <[email-masked]> wrote:

>> Without these metrics, it is impossible to determine whether PostgreSQL
>> is actually limiting throughput or whether the bottleneck is elsewhere.
>>
>> > If the application teams they are able achive only 60TPS and this is
>> not expected. They are calculating based on total suçcess requests/minutes
>> we ran load test*60.
>> >

---

From: Raj <[email-masked]>
Date: Fri, 5 Jun 2026 10:15:46 +0530

We font have any graphs...we have to monitor manually... I am using the OS
watch command to.monitor multiple metrics in multiple screens

On Fri, 5 Jun 2026, 10:14 Raj, <[email-masked]> wrote:

>>> > From Database side what we can do and during.load test what are
>>> all.the metric we need to monitor from our side. Vcpu 32, 128GB RAM
>>>
>>