---
title: "Connection Pool"
slug: "connection-pool"
category: "glossary"
tags: ["glossary", "backend", "database", "postgres", "performance", "concurrency"]
status: "stable"
last_updated: 2026-05-14
summary: "Connection pool maintains pre-established database connections for application threads to reuse, eliminating per-query connection overhead."
related:
  [
    "[[backend/postgres]]",
    "[[backend/prisma]]",
    "[[glossary/deadlock]]",
    "[[glossary/replication-lag]]",
    "[[glossary/sharding]]",
  ]
---

## Overview

This page is the atomic definition. PostgreSQL-specific connection management guidance lives at [[backend/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.

## Related concepts

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

## Citing this term

> See [[glossary/connection-pool|Connection Pool]] (llmbestpractices.com/glossary/connection-pool).

## Related

- [[backend/postgres]]
- [[backend/prisma]]
- [[glossary/deadlock]]
- [[glossary/replication-lag]]
- [[glossary/sharding]]