Postgres по QUIC: эксперимент с мультиплексированием транспорта
Ребята из Lupyd пропатчили пулер PgCat, чтобы он принимал QUIC-соединения (AWS s2n-quic), и пустили обычный wire-протокол Postgres по мультиплексированным QUIC-стримам.
Суть проблемы — не в базе. Протокол Postgres синхронный: одно соединение = один запрос в полёте. Если приложение живёт в 30 мс от пулера, клиентский пул из 10 TCP-соединений физически выдаёт не больше ~333 запросов/с (закон Литтла), а остальное копится в памяти процесса. Наращивать пул до тысяч сокетов больно: файловые дескрипторы, буферы ядра, TCP+TLS хендшейки по 30 мс и head-of-line blocking при потере пакета.
Что даёт QUIC. Новый стрим внутри уже установленного соединения — это просто номер в памяти: без сокета, без FD, без хендшейка. Потеря пакета тормозит только свой стрим. Клиента менять не надо: tokio-postgres принимает QUIC-стрим через connect_raw как обычный байтовый поток, TLS не дублируется — он уже внутри QUIC.
Результаты бенчмарка (Ryzen 7 5700X3D, netem 30 мс RTT, запрос ~0.5 мс, рампа 100 → 5000 QPS):
TCP, 500 соединений → QUIC, 50 соединений × 40 стримов
• Пиковая средняя задержка: 7088 мс → 246 мс
• Выполнено запросов: 4749 QPS → 9718 QPS
• Запросов в очереди: 36 041 → 40
• Память клиента (RSS): 474 МБ → 91 МБ
• CPU клиента: ~370 мс → ~970 мс (плата за user-space крипто и фрейминг)
Важные оговорки, которые автор проговаривает честно. QUIC не ускоряет саму БД: время выполнения запроса, блокировки и транзакционная семантика не меняются. Интерактивные транзакции BEGIN…COMMIT по-прежнему пиннят backend-соединение на все сетевые круги — тысячи стримов только быстрее исчерпают пул. Эффект ≈ доля сетевых round-trip в общем времени ответа: при co-located базе (<1 мс) или запросах по 20–100 мс выигрыша практически нет. Польза — кросс-регион и edge, много коротких одиночных запросов, каналы с потерями.
И это прототип, а не прод: нужен пропатченный PgCat, официальной поддержки QUIC в Postgres нет. Код и бенчмарк открыты.
Оригинал: https://blogs.lupyd.com/blog/postgres-with-quic/
Post #1287
128