TGViewer
Haiku Haiku @samurai_haiku · 452 subscribers
Post #1287 128
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/
Lupyd Blog Postgres with QUIC: Breaking the Client-Side Connection Bottleneck | Lupyd Why Postgres connection poolers still choke on client-side TCP bottlenecks, how QUIC stream multiplexing solves the 30ms latency wall, and real benchmark numbers.
  • 🔥 4
More from @samurai_haiku
  1. Sep 30, 2026Postgres — Don't Do This https://wiki.postgresql.org/wiki/Don%27t_Do_This Список антипатте…
  2. Sep 29, 2026🎙 XConf Europe 2026: пять самых просматриваемых докладов — код, суверенитет, LLM Wiki, ET…
  3. Sep 27, 2026🎙 Дайджест по лайкам: 20 избранных материалов (игриво) Column-store романтика (ClickHouse…
  4. Sep 27, 2026🎙 AI-дайджест: 20 последних новостей в одном выпуске (4 минуты) Две ведущих-нейросети соб…
  5. Sep 26, 2026Can I Let My AI Agent Run on Shabbat? Раввин Йосеф Бхор рассматривает галахический вопрос…
  6. Sep 26, 2026Наверное все уже видели :) https://youtu.be/b34vwOWLDXI?is=w6CgC0s6qXXfJH9I
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →