Proč potřebujete connection pooling (PgBouncer)?

Question

Accepted Answer

**Connection pooling** znovu používá malou sadu databázových připojení napříč mnoha klientskými požadavky, místo otevření nového připojení pro každý požadavek. PostgreSQL připojení jsou **drahá** (každé je samostatný proces využívající významnou paměť), takže pooling je nezbytný pro výkon a škálovatelnost pod zátěží. **PgBouncer** je standardní pooler.

## Problém: PostgreSQL připojení jsou drahá

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

## Řeš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 — standardní externí 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.
```

## Kde se pooling děje

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

## Proč je to důležité

Connection pooling je nezbytné znalosti pro provoz PostgreSQL **ve velkém měřítku**, protože PostgreSQL připojení jsou výjimečně drahá (každé je samostatný OS proces využívající významnou paměť), takže pochopení, proč je pooling potřebný a jak funguje, je důležité senior-level znalosti pro výkonná a škálovatelná nasazení.

Hlavní problém je, že naivní přístup — otevření připojení pro každý požadavek, nebo udržování tisíců otevřených připojení z vytížené aplikace — se neškáluje s Postgres: připojení jsou nákladná (paměť na proces, režie vytvoření), a Postgres má limit `max_connections` (často ~100), který je snadno překročen, což způsobuje chyby a vyčerpání zdrojů. **Connection pooling** to řeší tím, že udržuje malou sadu znovu použitelných připojení, která sdílí mnoho aplikačních požadavků (vypůjčuje si je a vrací je) — takže tisíce klientů mohou být obsluhováni několika desítkami databázových připojení, což eliminuje režii na požadavek a zůstává v limitu.

Pochopení **PgBounceru** (standardního externího pooleru) a jeho **pooling režimů** — zvláště **transaction pooling** (držení připojení pouze na dobu trvání transakce, maximalizující znovu použití, běžná volba pro webové aplikace) — je důležité praktické znalosti.

Vnímání **kde se pooling děje** (fondy na úrovni aplikace za instanci, versus externí pooler jako PgBouncer pro mnoho instancí nebo serverless) je klíčový architektonický bod — **serverless obzvláště potřebuje externí pooler**, protože mnoho krátkodobých instancí by jinak přetížilo Postgres připojeními (běžný, skutečný problém).

Protože správa připojení přímo ovlivňuje škálovatelnost a stabilitu pod zátěží (a Postgres model proces-na-připojení to činí akutním), a protože pooling (zejména PgBouncer s transaction pooling) je standardní, nezbytné řešení, je pochopení connection pooling — proč Postgres to potřebuje, jak to funguje, PgBouncer a jeho režimy, a serverless úvaha — důležité senior-level znalosti pro provoz PostgreSQL ve velkém měřítku, často kritické obavy pro produkční systémy, které rozlišují ty, kdo mohou škálovat Postgres od těch, kdo se setkávají se selháními překročení limitu připojení.