A connection pool can look perfectly reasonable when you inspect one application pod.
Ten connections? Fine.
Twenty? Maybe still fine.
But Kubernetes does not stop at one pod.
When the Horizontal Pod Autoscaler starts creating replicas, it also creates more copies of every client-side connection pool. Suddenly, what looked like a small local setting becomes a database-wide capacity problem.
That leads to a simple but important question:
- Have you multiplied your maximum pod count by the connection pool size?
If not, that calculation is worth doing before your busiest day does it for you.
The Hidden Multiplier
Suppose you have several Kubernetes workloads connecting to the same YugabyteDB cluster.
The connection math is:
If a pod creates more than one independent database pool, include those too.
The important word here is maximum.
Sizing against the three pods you normally run at 2:00 AM does not help when the autoscaler is allowed to create forty during a traffic spike.
Here’s an illustrative example:
Nothing about those individual pool sizes looks especially alarming.
Together, though, the application fleet can ask YugabyteDB to maintain 536 client connections.
Now Compare That With Backend Capacity
Without connection pooling at the database layer, PostgreSQL-style client connections are expensive because each server connection is backed by a PostgreSQL backend process.
YugabyteDB’s current sizing guidance (Right-size the cluster) recommends no more than about 15 server connections per vCPU as a baseline, and explicitly notes that latency-sensitive or high-throughput workloads may need fewer because CPU context switching increases as active connection counts grow.
Suppose the YugabyteDB cluster has:
At 15 server connections per vCPU:
A more conservative workload might plan around 10 active connections per vCPU:
Now compare that with the 536 possible application connections.
The point is not that 10 or 15 is universally correct.
The point is that you need to compare:
- How many client sessions can my application create?
against:
- How many active server backends should this cluster actually support?
Why Shrinking Every Client Pool Isn’t a Complete Solution
The obvious reaction is:
- Fine. I’ll just make every pool smaller.
That helps, but it has a limitation.
A pool inside one application pod has no awareness of:
- ● how many other pods exist,
- ● how many other microservices are connecting,
- ● whether another workload is scaling,
- ● or how many physical PostgreSQL backends the database should support.
Each pool enforces a local limit against a global database constraint.
That is the architectural mismatch.
YSQL Connection Manager Changes the Equation
YugabyteDB includes YSQL Connection Manager (YCM), a built-in server-side connection pooler.
When enabled, applications hold logical client connections, while YCM manages a smaller pool of physical PostgreSQL server connections underneath them.
Conceptually:
That is the important architectural change.
The Three Numbers I Would Write on the Whiteboard
When evaluating a Kubernetes application against YugabyteDB, I would collect these three numbers:
If #1 is much larger than #2, YCM has a lot of opportunity to multiplex sessions.
If #2 approaches #3, then the problem is no longer idle connection overhead.
It is actual query concurrency.
YCM Does Not Make Active Queries Free
This is an important distinction.
YCM can allow many idle or intermittently active client sessions to share fewer physical server connections.
But a client actively executing work needs a physical backend.
YugabyteDB’s YCM metrics documentation makes this explicit: the number of active logical connections equals the number of active server connections.
For example:
That does not mean YugabyteDB needs 536 active PostgreSQL backends.
At that moment, only the 72 active logical connections need to be attached to active physical server connections. The remaining client sessions can stay open without each permanently owning its own PostgreSQL backend.
Now compare that with:
That is a very different workload.
If all 536 logical connections are active at the same time, YCM needs 536 active server connections to service them concurrently. At that point, the limiting factor is no longer the number of idle client sessions, it is the amount of real concurrent database work the cluster is being asked to execute.
Enable YSQL Connection Manager
For a local yugabyted environment, you can enable YCM with:
./bin/yugabyted start \
--tserver_flags="enable_ysql_conn_mgr=true" \
--ui false
When enabled, each YB-TServer starts a YSQL Connection Manager process along with PostgreSQL.
For YugabyteDB Anywhere, use the platform’s Connection Pooling configuration rather than manually setting enable_ysql_conn_mgr, ysql_conn_mgr_port, or pgsql_proxy_bind_address.
First, Prove You’re Actually Using YCM
Before doing any connection-count testing, verify the session is really going through Connection Manager.
One quick check is:
SHOW yb_is_client_ysqlconnmgr;
Expected:
.yb_is_client_ysqlconnmgr
--------------------------
on
If it returns off, stop there. You are not measuring YCM behavior.
Don’t Just Count Connections – Watch Their State
YCM exposes per-pool statistics at:
http://<YB-TServer>:13000/connections
The current metrics distinguish between logical clients and physical servers, including:
These metrics are also exposed through Prometheus.
Here’s the Pattern I Would Watch For
The second situation is not evidence that YCM failed.
It means your workload is consuming real backend execution capacity.
One More Multiplier: Connection Distribution
There is another subtlety.
YCM runs on each YB-TServer, and YugabyteDB’s current best-practice guidance recommends combining Connection Manager with Smart Drivers so connections are distributed efficiently across nodes.
A cluster-wide calculation such as:
assumes the workload is reasonably balanced.
If most client sessions land on one YB-TServer, that node can encounter connection or CPU pressure while other nodes still have room.
What About Sticky Connections?
Not every logical connection is equally reusable.
Session state, temporary objects, and other features can cause a client connection to become sticky, meaning its physical backend cannot immediately return to the shared pool.
YugabyteDB recommends reducing stickiness where possible to maximize server-connection reuse.
Client Pools and YCM Are Not Competitors
You do not necessarily have to throw away HikariCP, Tomcat pooling, or another application-side pool just because YCM exists.
They solve different problems.
YugabyteDB’s client best-practice documentation specifically discusses using popular application pools together with YugabyteDB Smart Drivers and YSQL Connection Manager.
A 60-Second Preflight Check
Before deploying an autoscaling application, answer these questions:
If you do that math before production traffic arrives, a connection spike becomes a capacity-planning exercise instead of an outage investigation.
Related YugabyteDB Tips
These earlier Tips go deeper into specific parts of this topic:
Final Takeaway
Kubernetes makes scaling an application easy.
It also makes it very easy to multiply database connections without realizing it.
A pool size that looks harmless on one pod can become hundreds or thousands of sessions once several independently autoscaling services are added together.
YSQL Connection Manager changes the architecture by separating logical client sessions from physical PostgreSQL backends.
But there is one number it cannot make disappear:
- actual concurrent work.
Have Fun!
My wife woke up, looked at me, and said, “Happy Anniversary!” Uh-oh. 😳 Between our cross-country move and an upcoming business trip to D.C., I had completely forgotten. My brain had apparently already been packed in a box.
Luckily, she was coming along and I managed to sneak a visit to the Smithsonian’s National Zoo into the trip so she could see the pandas. She LOVES pandas. 🐼 Crisis averted. Phew!
Here’s Qing Bao enjoying her bamboo, blissfully unaware she just helped save a husband’s hide. 😂