Hvorfor skal du bruge connection pooling (PgBouncer)?

Question

Accepted Answer

**Connection pooling** genbruger et lille sæt databaseforbindelser på tværs af mange klientforespørgsler i stedet for at åbne en ny forbindelse pr. forespørgsel. PostgreSQL-forbindelser er **dyre** (hver er en separat proces, der bruger betydelig hukommelse), så pooling er essentielt for ydeevne og skalerbarhed under belastning. **PgBouncer** er standard-pooleren.

## Problemet: PostgreSQL-forbindelser er dyre

```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.
```

## Løsningen: en 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 — standard ekstern 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.
```

## Hvor pooling finder sted

```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).
```

## Hvorfor det betyder noget

Connection pooling er essentiel viden for at køre PostgreSQL **i stor skala**, fordi PostgreSQL-forbindelser er unikt dyre (hver er en separat OS-proces, der bruger betydelig hukommelse), så det at forstå, hvorfor pooling er nødvendig, og hvordan det fungerer, er vigtig knowledge på seniorniveau for performante, skalérbare deployments.

Kerneproblemmet er, at den naive tilgang — at åbne en forbindelse pr. forespørgsel, eller at holde tusindvis af forbindelser åbne fra en travl applikation — ikke skalerer med Postgres: forbindelser er kostbare (hukommelse pr. proces, oprettelses-overhead), og Postgres har en `max_connections`-grænse (ofte ~100), der nemt overskrides, hvilket forårsager fejl og ressource-udtømning. **Connection pooling** løser dette ved at vedligeholde et lille sæt af genbrugelige forbindelser, som mange applikationsforespørgsler deler (låner og returnerer) — så tusindvis af klienter kan betjenes af få dusin databaseforbindelser, hvilket eliminerer pr.-forespørgsel-overhead og holder sig inden for grænserne.

At forstå **PgBouncer** (standard ekstern pooler) og dets **pooling modes** — især **transaction pooling** (at holde en forbindelse kun for en transaktions varighed, maksimering af genbrug, det almindelige valg for web apps) — er vigtig praktisk viden.

At vide **hvor pooling finder sted** (application-level pools pr. instans versus en ekstern pooler som PgBouncer for mange instanser eller serverless) er et centralt arkitektur-punkt — **serverless har især brug for en ekstern pooler**, fordi mange kortlivede instanser ellers ville overvælde Postgres med forbindelser (et almindeligt, reelt problem).

Da forbindelses-management direkte påvirker skalerbarhed og stabilitet under belastning (og Postgres's process-per-connection-model gør dette akut), og da pooling (især PgBouncer med transaction pooling) er standard, vigtig løsning, er forståelse af connection pooling — hvorfor Postgres har brug for det, hvordan det fungerer, PgBouncer og dets modes, og serverless-hensynet — vigtig knowledge på seniorniveau for at drive PostgreSQL i stor skala, et hyppigt kritisk område for produktionssystemer, der skelner dem, der kan skalere Postgres, fra dem, der rammer connection-limit-fejl.