Overview

This page is the atomic definition. PostgreSQL-specific connection management guidance lives at postgres.

Definition

A connection pool is a cache of open database connections managed by a pool manager so that application code can borrow a connection, use it, and return it without the cost of a full TCP handshake, authentication, and TLS negotiation on every query. PostgreSQL forks a backend process for each connection; without pooling, a service that opens 1,000 simultaneous connections consumes gigabytes of memory in backend processes. Tools like PgBouncer (transaction-mode pooling), pgpool-II, and Prisma’s built-in pool multiplex application connections onto a smaller set of actual server connections. Pool configuration has two critical parameters: min (connections to keep warm at idle) and max (ceiling before new requests queue). Setting max too high exhausts PostgreSQL’s max_connections limit; setting it too low creates latency spikes under load. In serverless environments, short-lived function instances each open their own pools, which leads to connection exhaustion; a proxy such as PgBouncer or Supabase Pooler sits between functions and Postgres.

When it applies

Use a connection pool for every production database connection. The pool lives in the application process (Prisma, SQLAlchemy pool) or as an external proxy (PgBouncer). Configure max to stay well below the server’s max_connections. Monitor pool wait time as a leading indicator of connection pressure.

Example

A Node.js API using Prisma sets connection_limit=10 in the database URL. At 50 concurrent requests, 40 requests queue briefly while 10 execute in parallel against the database. Total server connections stay at 10 instead of 50. Database memory usage is stable under load.

  • postgres - PostgreSQL’s process-per-connection model makes pooling essential.
  • prisma - Prisma’s Data Proxy and built-in pool handle connection limits in serverless.
  • deadlock - deadlocks can exhaust pool connections when transactions hold connections while waiting.
  • sharding - sharded databases multiply the pool count; each shard needs its own pool.

Citing this term

See Connection Pool (llmbestpractices.com/glossary/connection-pool).