read_heavy_api benefits from connection

read heavy apiBenefits Fromconnection pooling

Source: Workload·Target: Pattern

Summary

Read-heavy APIs generate large numbers of short-lived database connections. Connection pooling reduces per-request connection overhead and allows the database to serve far more concurrent requests than its max_connections limit.

Evidence

·Connection overhead for PostgreSQL is 1–5ms; pooling eliminates this per request
·APIs serving 10k+ RPS typically run 50–200 app replicas against 1–2 database instances
·PgBouncer transaction-mode pooling documented to support 10x more app instances

Operational Context

·Most effective when application uses short-lived, stateless database interactions
·Pair with read replicas to further distribute connection load
·Minimum pool configuration: min_pool_size=5, max_pool_size=20 per replica

Tradeoffs

·Pool idle connections consume database resources even under low load
·Under sustained load, pool queue wait times add latency

Generator Relevance

Read-heavy API workload profiles should always include connection pooling in recommended_patterns output.

Evidence grounding

Grounded, 3 supporting items

Standard operational practice. The benefit is proportional to the read volume and connection churn rate, both of which are high in this workload class.