Server
Connection pool
Connection pool is a fixed set of already-open database connections that requests borrow and return. It saves the cost of opening a new one for every query.
How it is measured
Track pool size, connections in use, waiters in the queue and the time spent waiting for a free connection. The wait time is the one that shows pain, because it adds directly to every request that needs the database.
Compare the pool maximum, multiplied by the number of app instances, against the database's own limit such as max_connections. If the product is larger than the limit, the pool will fail before the database is busy.
Worked example
A Laravel app runs on 6 instances, each with a pool of 20, against a Postgres server that allows 100 connections. During a traffic jump, instances 5 and 6 cannot get a slot, and requests fail with 'too many clients' even though the database CPU sits at 30 percent.
Dropping the pool to 10 per instance gives 60 connections, leaves headroom for migrations and cron, and a pooler in front lets the fleet grow without tripping the limit.
How it differs
A connection pool reuses database connections. A thread pool reuses threads for work inside the server. The pool excludes new connection setup, a thread pool excludes new thread creation. A thread can be waiting on a connection, so a small connection pool can leave plenty of threads idle and a request still slow.
Common errors
Setting the pool as large as the database allows on each instance. Leaking connections by not releasing on error paths. Holding a connection open during a slow HTTP call to a third party. Forgetting serverless functions each open their own. Not setting a wait timeout so requests queue forever.
In practice
Calculate instances times pool size and compare to the database limit this week. Add a metric for pool wait time, put a pooler like PgBouncer or ProxySQL in front if you run many short-lived processes, and make sure every code path returns its connection.