PgBouncer пуллинг соединений для PostgreSQL

В отличие от MySQL (thread-based) или MongoDB (event-based), PostgreSQL использует process-per-connection архитектуру. Каждое клиентское соединение - отдельный OS-процесс с своим адресным пространством, ~10 MB shared memory оверхед, переключение контекста CPU при каждом запросе. На малых нагрузках это даёт изоляцию и стабильность. На больших нагрузках это катастрофа. 1000 соединений - уже 10 GB RAM только под Postgres backends, плюс работа основного executor-а. 10000 соединений - физически невозможно без огромного железа. Реальная проблема - современные веб-приложения с auto-scaling могут иметь сотни инстансов, каждый держит pool 10-20 соединений. Без pooler-а Postgres падает. PgBouncer мультиплексирует тысячи клиентов через 25-100 серверных соединений. Один Postgres backend обслуживает много клиентов последовательно (transaction pooling) или параллельно через query slicing.

PgBouncer поддерживает три режима. Session pooling - клиент держит соединение всё время сессии. Безопасно, но не даёт прироста по соединениям. Используется когда клиент использует временные таблицы, prepared statements, advisory locks. Transaction pooling - клиент получает соединение только на время транзакции, после COMMIT возвращает в pool. Большинство приложений работают в этом режиме. Прирост в 10-100 раз по числу клиентов. Ограничения: нельзя использовать prepared statements (с PgBouncer 1.21+ можно), временные таблицы, SET command вне транзакции. Statement pooling - соединение возвращается после каждого SQL statement. Только для read-only без транзакций. Очень редко используется. Для типичного веб-приложения transaction pooling даёт оптимальный баланс. Pool size настраивается per-database и per-user.

PgBouncer - крошечный single-threaded демон на C, 1 MB бинарника. Обрабатывает 10-50k req/sec на одном ядре. Конфигурируется через pgbouncer.ini: список баз с pool settings, список users с auth_type (MD5, SCRAM, trust), max_client_conn (десятки тысяч), default_pool_size (25-100), reserve_pool_size для пиков. Аутентификация через userlist.txt с хешами паролей, или через PostgreSQL pg_authid lookup. Мониторинг через специальные SHOW команды: SHOW POOLS показывает использование, SHOW STATS - запросы в секунду, SHOW CLIENTS - кто сейчас подключён. Метрики экспортируются в Prometheus через pgbouncer_exporter. Для high availability ставим 2 PgBouncer в active-active с HAProxy перед ними. Стандартная конфигурация: PgBouncer на том же VPS что и Postgres, доступ через localhost socket для минимизации overhead.