Zašto trebate connection pooling (PgBouncer)?

Question

Accepted Answer

**Connection pooling** ponovno koristi mali skup konekcija baze podataka preko mnogih zahtjeva klijenta umjesto otvaranja nove konekcije po zahtjevu. PostgreSQL konekcije su **skupe** (svaka je zaseban proces koji koristi značajnu memoriju), pa je pooling neophodan za performanse i skalabilnost pod opterećenjem. **PgBouncer** je standard pooler.

## Problem: PostgreSQL konekcije su skupe

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

## Rješenje: 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 vanjski 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.
```

## Gdje se pooling događa

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

## Zašto je to važno

Connection pooling je bitno znanje za pokretanje PostgreSQL-a **u velikoj skali**, jer su PostgreSQL konekcije jedinstveno skupe (svaka je zaseban OS proces koji koristi značajnu memoriju), pa razumijevanje zašto je pooling potreban i kako funkcionira je važno znanje za seniore za performantne, skalabilne implementacije.

Osnovni problem je što naivni pristup — otvaranje konekcije po zahtjevu ili держavanje tisućа konekcija otvorenih iz aktivne aplikacije — nije skalabilan s Postgre: konekcije su skupe (memorija po procesu, overhead kreiranja), a Postgres ima `max_connections` ograničenje (često ~100) koje se lako premaši, što uzrokuje greške i iscrpljivanje resursa. **Connection pooling** rješava to održavanjem malog skupa ponovno iskoristivih konekcija koje dijele mnogi zahtjevi aplikacije (pozajmljujući i vraćajući ih) — pa tisuće klijenata mogu biti poslužene s nekoliko desitaka konekcija baze podataka, eliminirajući overhead po zahtjevu i ostajući unutar ograničenja.

Razumijevanje **PgBouncera** (standard vanjski pooler) i njegovih **pooling modusa** — posebno **transaction pooling** (držanje konekcije samo tijekom trajanja transakcije, maksimalnoj ponovnoj iskoristivosti, česti izbor za web aplikacije) — je važno praktično znanje.

Znanje **gdje se pooling događa** (application-level poolovi po instanci nasuprot vanjskom pooleru kao što je PgBouncer za mnogo instanci ili serverless) je ključna arhitekturna točka — **serverless posebno treba vanjski pooler** jer bi mnogo kratkovječnih instanci inače preplavilo Postgres konekcijama (čest, pravi problem).

Budući da upravljanje konekcijama direktno utječe na skalabilnost i stabilnost pod opterećenjem (i budući da Postgresov process-per-connection model to čini ozbiljno), i budući da je pooling (posebno PgBouncer s transaction poolingom) standard, neophodno rješenje, razumijevanje connection poolinga — zašto Postgres ga treba, kako funkcionira, PgBouncer i njegovi modusi, i razmatranje serverless — je važno znanje za seniore za upravljanje PostgreSQL-om u velikoj skali, često kritična briga za produkcijske sustave koji razlikuju one koji mogu skalirati Postgres od onih koji naiđu na connection-limit greške.