managing-postgres-connectionslisted

# Managing Postgres Connections ## Overview A Postgres connection is a server process with memory and scheduling cost. Bound concurrency across all application instances and preserve an operational reserve. Raising `max_connections` does not create capacity. ## Choose the pooling layer Prefer PgBouncer when many processes share a database: it enforces one server budget. Use an in-process pool such as Go's `pgxpool` when necessary, but multiply its maximum by every replica and process. Use this mode decision for PgBouncer: | Mode | Use | Required warning | |---|---|---| | **Transaction (default)** | Stateless web/request workloads | A later transaction may use another backend; session state is not preserved | | Session | Compatible fallback for session-dependent code | Idle clients retain server connections, so multiplexing is less efficient | | Statement | Rare, independent autocommit statements only | Cannot run multi-statement transactions; unsuitable for most apps | **Transaction pooling breaks assumptions about session-level prepared statements, session-level advisory locks, `LISTEN`/`NOTIFY`, session variables, cursors held across transactions, and temporary tables.** Use transaction-level locks, `SET LOCAL`, and transaction-scoped cursors where possible; otherwise use a dedicated session-pooled or direct connection. For pgx, never assume its implicit prepared-statement cache is compatible with transaction pooling. Either configure and test PgBouncer protocol-lev