Waarom heb je connection pooling nodig (PgBouncer)?

Question

Accepted Answer

**Connection pooling** hergebruikt een kleine set databaseverbindingen over veel clientverzoeken, in plaats van per verzoek een nieuwe verbinding te openen. PostgreSQL-verbindingen zijn **duur** (elk is een apart proces dat aanzienlijk geheugen gebruikt), dus pooling is essentieel voor prestaties en schaalbaarheid onder belasting. **PgBouncer** is de standaard pooler.

## Het probleem: PostgreSQL-verbindingen zijn duur

```text
Each PostgreSQL connection = a separate OS PROCESS, using ~5-10MB of memory.
  ✗ Opening a connection has overhead (process creation, auth, setup)
  ✗ Many connections (e.g. 1000s from a busy app) → huge memory use, contention
  ✗ Postgres has a max_connections limit (often ~100); exceeding it = errors
→ Opening/closing a connection per request, or holding thousands open, doesn't scale.
```

## De oplossing: een connection pool

```text
A POOL maintains a small set of REUSABLE connections to Postgres.
Application requests BORROW a connection from the pool, use it, and RETURN it.
  ✓ Connections are reused (no per-request open/close overhead)
  ✓ Many app requests share a few DB connections (e.g. 10000 clients → 20 connections)
  ✓ Stays within max_connections, controls resource use → scales
```

## PgBouncer — de standaard externe pooler

```text
PgBouncer sits BETWEEN the application and PostgreSQL — lightweight, efficient.
Pooling modes:
  Session   → a connection is assigned for the client's whole session
  Transaction → a connection is held only for the duration of a TRANSACTION (most
               efficient — connections returned between transactions; common choice)
  Statement → per-statement (most aggressive; limited)
→ Transaction pooling maximizes connection reuse for typical web apps.
```

## Waar pooling gebeurt

```text
Application-level → many ORM/driver libraries have built-in pools (per app instance)
External pooler (PgBouncer) → a shared pool in front of Postgres (best for many app
  instances / serverless, where per-instance pools would still overwhelm the DB)
→ Serverless especially needs an external pooler (many short-lived instances).
```

## Waarom het belangrijk is

Connection pooling is essentiële kennis voor het uitvoeren van PostgreSQL **op schaal**, omdat PostgreSQL-verbindingen uniek duur zijn (elk is een apart OS-proces dat aanzienlijk geheugen gebruikt), dus begrip van waarom pooling nodig is en hoe het werkt, is belangrijke senior-level kennis voor performante, schaalbare implementaties.

Het kernprobleem is dat de naïeve benadering — per verzoek een verbinding openen, of duizenden verbindingen geopend houden vanuit een drukke applicatie — niet schaalt met Postgres: verbindingen zijn kostbaar (geheugen per proces, aanmaakoverhead), en Postgres heeft een `max_connections`-limiet (vaak ~100) die gemakkelijk wordt overschreden, waardoor fouten en resource-uitputting optreden. **Connection pooling** lost dit op door een kleine set herbruikbare verbindingen te onderhouden die veel toepassingsverzoeken delen (ze lenen en teruggeven) — dus duizenden clients kunnen worden bediend door enkele tientallen databaseverbindingen, waardoor per-verzoek overhead wordt geëlimineerd en limieten worden gehandhaafd.

Begrijpen van **PgBouncer** (de standaard externe pooler) en de bijbehorende **pooling-modi** — vooral **transaction pooling** (een verbinding alleen voor de duur van een transactie aangehouden, maximalisering van hergebruik, de gebruikelijke keuze voor web-apps) — is belangrijke praktische kennis.

Weten **waar pooling gebeurt** (application-level pools per instantie, versus een externe pooler als PgBouncer voor veel instanties of serverless) is een belangrijk architecturaal punt — **serverless heeft vooral een externe pooler nodig** omdat veel kortlevende instanties anders Postgres zouden overstelpen met verbindingen (een veelvoorkomend, reëel probleem).

Omdat verbindingsbeheer rechtstreeks invloed heeft op schaalbaarheid en stabiliteit onder belasting (en Postgres's process-per-connection model maakt dit acuut), en omdat pooling (vooral PgBouncer met transaction pooling) de standaard, essentiële oplossing is, is het begrijpen van connection pooling — waarom Postgres het nodig heeft, hoe het werkt, PgBouncer en de bijbehorende modi, en het serverless-aspect — belangrijke senior-level kennis voor het bedrijven van PostgreSQL op schaal, een vaak kritieke zorg voor productiesystemen die degenen die Postgres kunnen schalen, onderscheiden van degenen die connection-limit-fouten ondervinden.