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 <rajeshkumar.dba09@gmail.com> 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
