Your Client Connection Pool isn’t the Problem

Kubernetes autoscaling can multiply per-pod client connection pools until a database’s physical connection capacity is exceeded, even when most connections are idle. A YugabyteDB customer running two HikariCP-based services could have required 1,920 connections at their maximum 64 pods each, while its three-node, 24-vCPU cluster was sized for roughly 360 YSQL backends under PostgreSQL’s process-per-connection model. Adding enough hardware to support the theoretical peak would have required about five times more compute primarily to maintain idle backend processes, while reducing individual pool sizes would not solve the cluster-wide scaling issue without application changes. By enabling YugabyteDB’s built-in YSQL Connection Manager, the customer retained its existing application code, Hikari settings, autoscaling configuration, and cluster size while multiplexing logical client connections over a smaller pool of physical backends. The connection manager, based on a modified Odyssey pooler and operating in transaction-pooling mode, provides a PostgreSQL-compatible endpoint without a separate proxy tier, although long transactions and session features that pin connections can reduce multiplexing efficiency.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.