Ландшафт пулеров 2026, serverless connection storms и полная таксономия отказов

B2B SaaS на Postgres достигает 5 000 QPS пика. Что использовать — PgBouncer, Odyssey, PgCat, Supavisor или RDS Proxy? Ответ зависит от того, в чём узкое место: однопоточная пропускная способность, serverless cold start, масштаб multi-tenant или маршрутизация к read-репликам.

Ландшафт пулеров 2026

PgBouncer по-прежнему production-рабочая лошадка: однопоточный C, ~2 КБ на pooled-соединение, battle-tested за десятилетие, 1.21+ закрывает пробел с prepared statements. Используйте, когда нужен минималистичный, хорошо понятный пулер, располагающийся рядом с Postgres. Ограничение: однопоточность означает потолок одного ядра CPU для пропускной способности PgBouncer; при очень высоком QPS через один инстанс нужно несколько PgBouncer за HAProxy.

Odyssey (команда Яндекс/Tarantool): многопоточный C, нативно поддерживает prepared statements, показывает наименьшие накладные расходы CPU при высокой конкурентности в бенчмарках. Используйте, когда один нод PgBouncer становится узким местом по CPU (более ~100k QPS через один пулер). Компромисс: меньше сообщество, меньше операторов знакомо с ним.

PgCat (Rust): многопоточный, добавляет маршрутизацию запросов (read-реплики, шардинг) поверх пулинга. Используйте, когда нужен один компонент для пула, балансировки replica и маршрутизации запросов. Молодая кодовая база.

Supavisor (Supabase, Elixir/Erlang): cloud-native, спроектирован для serverless и multi-tenant SaaS, обрабатывает миллионы входящих соединений через легковесные Erlang-процессы. Используйте, когда входящих соединений массово много — serverless cold start, edge-функции, B2B SaaS с тысячами tenant-баз данных.

pgpool-II: традиционный выбор, объединяющий HA, балансировку read-нагрузки и пулинг. Тяжелее и сложнее; используется в legacy-развёртываниях, но менее популярен для greenfield.

Serverless и edge: connection storm

Serverless-платформы (Lambda, Vercel Functions, Cloudflare Workers) при нагрузке холодно запускают сотни и тысячи воркеров. Каждый cold start открывает одно или несколько Postgres-соединений — connection storm. Даже при клиентских пулах каждый cold start открывает новое соединение до прогрева пула.

Паттерны смягчения:

1. Всегда ставить пулер перед Postgres: RDS Proxy на AWS, Supavisor перед Supabase, PgBouncer на постоянном ноде. Пулер поглощает connection storm; Postgres видит ограниченное число backend’ов.

2. HTTP-based драйвер для edge: серверлесс-драйвер Neon и Cloudflare Hyperdrive отправляют запросы через stateless HTTP к endpoint пулера — от edge-воркеров до origin нет постоянных соединений. Каждый запрос — один HTTP-запрос; пулер за ним поддерживает реальные Postgres-соединения.

3. Агрессивные idle-таймауты: serverless-воркеры короткоживущие; простаивающие клиентские соединения от мёртвых воркеров должны быстро освобождаться. Устанавливайте idle_client_timeout на пулере и tcp_keepalives_idle в Postgres для обнаружения мёртвых соединений.

Архитектурный урок: постоянные пулы соединений предполагают долгоживущих клиентов. Serverless нарушает это. Проектируйте для stateless dispatch запросов; делегируйте управление постоянными соединениями расположенному рядом пулеру.

Таксономия режимов отказов

Восемь режимов отказов:

(а) Исчерпание пула из-за медленных запросов: отсутствующий индекс делает запрос за 5 с; при 1 000 QPS это 5 000 backend’ов в полёте, превышающих любой пул. Исправление: проиндексировать запрос, пагинировать большие сканы.

(б) Idle-in-transaction опустошает пул: необработанное исключение или внешний API-вызов внутри BEGIN оставляет backend’ы в idle in transaction. Исправление: idle_in_transaction_session_timeout = 60s; code review на отсутствие try/finally; outbox-паттерн для write-then-event.

(в) Внешний API внутри транзакции: BEGIN → платёж Stripe (таймаут = 120 с) → COMMIT. Каждый запрос в полёте удерживает backend до 120 с. Исправление: COMMIT перед вызовом; outbox-паттерн.

(г) NAT/фаервол тихо дропает TCP: backend выглядит простаивающим для PgBouncer, но TCP-сокет мёртв. Новые запросы получают RST или таймаут. Исправление: tcp_keepalives_idle = 60s в postgresql.conf; tcp_keepalives_interval = 10s; client_connection_check_interval = 30s (Postgres 14+).

(д) Коллизии prepared statements (до PgBouncer 1.21): устаревший код с SQL-level PREPARE + transaction mode = “prepared statement does not exist” случайным образом. Исправление: обновить до PgBouncer 1.21+ + max_prepared_statements > 0; или переписать на prepared statements уровня протокола драйвера.

(е) Утечка состояния между клиентами (DISCARD ALL не срабатывает): SET без LOCAL утекает от одного клиента к следующему через пул. Исправление: server_reset_query = DISCARD ALL в pgbouncer.ini; аудит на голые SET.

(ж) Неправильный размер пула для пика vs стабильного состояния: пул рассчитан на стабильную нагрузку; всплески его исчерпывают. Исправление: reserve_pool_size ~25% от pool_size; автомасштабирование на уровне приложения; очередь с деградацией (возвращать 503 с Retry-After до полного исчерпания).

(з) Потолок однопоточного CPU PgBouncer при экстремальном QPS: при очень высоком QPS один нод PgBouncer занимает одно ядро CPU. Исправление: горизонтальное масштабирование PgBouncer за HAProxy/keepalived для VIP-failover; или мигрировать на Odyssey/PgCat.