Прокси или пулер соединений PostgreSQL — это приложение-посредник, которое находится между вашими клиентскими приложениями и одним или несколькими серверами PostgreSQL. Оно использует сетевой протокол PostgreSQL, что позволяет любому стандартному клиенту (например, вашему веб-серверу или приложению на Java/Python/Go) подключаться к посреднику, считая, что он общается напрямую с сервером PostgreSQL.

В отличие от MySQL, где прокси часто применяются для разделения запросов на чтение/запись (R/W split) или кэширования, в мире PostgreSQL основная задача посредника — эффективное управление соединениями.

Проблема: “Process per Connection” в PostgreSQL

PostgreSQL исторически использует модель process per connection, где на каждое новое клиентское соединение создается отдельный процесс postgres. Это надежная, но ресурсоемкая модель: каждый процесс потребляет примерно 10–20 МБ RAM, плюс накладные расходы на fork/exec.

Если ваше приложение открывает сотни или тысячи коротких соединений (например, микросервисы, FaaS, веб-приложения), сервер БД перегружается: растёт нагрузка на CPU от fork, исчерпывается память, соединения “затыкаются”.

Решение — connection pooling. Именно этим занимаются PgBouncer, Pgpool-II, Odyssey и их аналоги.

Как работает посредник для PostgreSQL

В базовой конфигурации пулер просто перенаправляет запросы от клиента к серверу PostgreSQL. Но его ключевая функция — мультиплексирование соединений:

1. Прием — клиентское приложение подключается к пулеру (например, PgBouncer).

2. Ожидание — пулер держит готовый пул реальных соединений с сервером PostgreSQL (уже аутентифицированных).

3. Маршрутизация — при запросе клиента:

   • пулер берет свободное соединение из пула;
   • выполняет транзакцию клиента;
   • возвращает соединение обратно в пул, сбрасывая состояние.

4. Ответ — результат возвращается клиенту.

Итог: тысячи клиентских “легких” соединений обрабатываются десятками “тяжелых” соединений к базе. Экономия ресурсов — в десятки раз.

Основные функции и задачи

Некоторые прокси также поддерживают query caching, сбор статистики и экспортеры для Prometheus.

Типы посредников для PostgreSQL

1. Легковесные пулеры соединений (Layer 7, не SQL-aware)

Они понимают протокол PostgreSQL, но не парсят SQL-запросы. Главная цель — быстрое мультиплексирование с минимальной задержкой (<1 мс).

Режимы пулинга:

• Session — соединение держится до дисконнекта (удобно, но не экономит ресурсы).
• Transaction — соединение выдается на время транзакции (BEGIN…COMMIT). Оптимальный баланс.
• Statement — соединение на один запрос (максимальная экономия, но строгие ограничения).

2. SQL-aware прокси (понимают SQL)

Они разбирают SQL-трафик, что позволяет делать R/W split, кэширование и анализ запросов.

3. TCP/Layer 4 прокси (не понимают протокол)

Примеры конфигураций

PgBouncer (пулинг транзакций)

[databases]
my_app_db = host=127.0.0.1 port=5432 dbname=real_db_name

[pgbouncer]
listen_port = 6432
listen_addr = *
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction  ; Рекомендуемый режим
max_client_conn = 2000
default_pool_size = 20   ; Подбирайте под RAM/CPU (~10–50 на ядро)
reserve_pool_size = 5

Pgpool-II (R/W split и HA)

listen_addresses = '*'
port = 9999

enable_pooling = on
num_init_children = 32
max_pool = 4

backend_hostname0 = 'primary_host'
backend_port0 = 5432
backend_weight0 = 1.0

backend_hostname1 = 'replica_host'
backend_port1 = 5432
backend_weight1 = 1.0

load_balance_mode = on
primary_node_id = 0
watchdog_enable = on

Odyssey (многопоточный YAML-конфиг)

daemonize: false
pid_file_path: /tmp/odyssey.pid

listeners:
  - host: 0.0.0.0
    port: 6432
    database: my_app_db
    users:
      - name: app_user
        password: secret
        pool_size: 20
        pool_mode: transaction

storage:
  - name: postgres
    type: remote
    hosts:
      - host: 127.0.0.1
        port: 5432

Как выбрать инструмент

Best Practices

• Мониторинг: используйте SHOW STATS; (PgBouncer) или Prometheus-экспортеры.
• Размер пула: default_pool_size = (RAM / 20MB) / databases, но не больше 100–200 на сервер.
• Безопасность: включите sslmode=require и терминируйте TLS в пулере.
• Нагрузка: тестируйте через pgbench, добиваясь <5 мс задержки.
• Kubernetes: ставьте PgBouncer как sidecar, HAProxy — как DaemonSet.

Заключение

В экосистеме PostgreSQL пулер соединений — не опция, а необходимость для любой высоконагруженной системы (100+ RPS).

• Начинайте с PgBouncer — он решает 90% проблем с соединениями.
• Используйте Pgpool-II, если нужен встроенный R/W split и query cache.
• Применяйте Odyssey или PgCat для современных масштабных сетапов.
• Добавьте HAProxy + Patroni, если требуется HA и репликация на уровне TCP.

С правильно выбранным посредником ваш PostgreSQL выдержит тысячи клиентов и останется спокойным, как слон 🐘.