Haiku

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/

Postgres — Don't Do This
https://wiki.postgresql.org/wiki/Don%27t_Do_This

Список антипаттернов из официальной вики PostgreSQL. Простыми словами:

1. SQL_ASCII — база складывает байты без проверки, получается каша из кодировок, которую не разобрать. Берите UTF-8.
2. psql -W / --password — спрашивает пароль даже когда он не нужен, путает диагностику доступа. psql сам спросит, если надо.
3. RULE — выглядит как логика, а молча переписывает запрос; все нетривиальные правила неверны. Нужен побочный эффект — триггер.
4. Наследование таблиц — мода на «БД как объекты», не взлетела. Связи — внешними ключами.
5. NOT IN — с NULL всегда 0 строк; с подзапросом планировщик не делает anti-join, получается квадратичный перебор и падение скорости в тысячи раз на росте данных. Пишите NOT EXISTS.
6. Имена MyTable — без кавычек всё приводится к нижнему регистру, с кавычками нет; вечные «no such table». Пишите my_table.
7. BETWEEN с timestamp — включает обе границы, ровно полночь считается дважды. Пишите >= начало AND < конец.
8. timestamp без зоны — это «фотография часов», а не момент времени; арифметика через переход на летнее время врёт. Берите timestamptz.
9. UTC в timestamp without time zone — база не знает, что это UTC, и любой расчёт превращается в цепочку AT TIME ZONE.
10. timetz и CURRENT_TIME — время с зоной без даты бессмысленно. Берите now() / CURRENT_DATE / LOCALTIMESTAMP.
11. timestamp(0) — округляет, а не отрезает, время «уезжает» вперёд. Нужна секунда — date_trunc('second', x).
12. char(n) — добивает пробелами, тратит место, не быстрее и странно сравнивается. Даже для кодов стран: text + CHECK(length(...)=3).
13. varchar(255) по привычке — text занимает ровно столько же и не медленнее; случайный лимит однажды уронит прод. Лимит — только осознанно.
14. money — не хранит валюту (зависит от настройки lc_monetary), не умеет доли цента, округляет не так. Берите numeric + колонку валюты.
15. serial — устаревшая автонумерация с неудобными зависимостями и правами. В новом коде — GENERATED AS IDENTITY.
16. trust-аутентификация по TCP/IP — сервер верит на слово, кем вы представились. host all all 0.0.0.0/0 trust = любой из интернета входит суперпользователем. Только scram-sha-256.

Проверить свою схему автоматически: schemalint — https://github.com/kristiandupont/schemalint

🎙 XConf Europe 2026: пять самых просматриваемых докладов — код, суверенитет, LLM Wiki, ETL и легаси. 15 минут с цитатами и лёгкой иронией.

🎙 Дайджест по лайкам: 20 избранных материалов (игриво)

Column-store романтика (ClickHouse + CAS от Altinity, DuckDB×Jev), модели на диете (Bonsai 2 27B, прунинг как задача Изинга, Alice AI от Яндекса, Jina OCR), потолок масштабирования от MIT и аудит завышения токенов у провайдеров, медицинский блок (fhir-tx-encoder для R, федеративное обучение OHDSI, CSIRO про потоки пациентов, GenHealth×eClinicalWorks) и агенты (LiteParse, доказательства вместо ревью, KeiroLabs).

4:45 · озвучено Gemini 3.8 Flash TTS, два голоса одним проходом, 11 центов.

🎙 AI-дайджест: 20 последних новостей в одном выпуске (4 минуты)

Две ведущих-нейросети собрали ленту в шесть тем: скепсис Рамеза Наама про «взрыв интеллекта», агенты в разработке (автономный багфиксинг, ревью-затор в Google), рекуррентность вместо глубины и self-play без данных, доступ к GLM 5.3 FlashX, чёрный список Пентагона для Anthropic и — на десерт — танцующие какапо Саймона Уиллисона.

Озвучено Gemini 3.8 Flash TTS, два голоса в одном проходе. 4:04 аудио, стоимость выпуска — 9,4 цента.

Can I Let My AI Agent Run on Shabbat?

Раввин Йосеф Бхор рассматривает галахический вопрос о запуске ИИ-агентов в Шаббат. Он анализирует, нарушает ли автоматическое выполнение задач ИИ-системой традиционные еврейские законы о работе в святой день, и приходит к выводу, что это зависит от конкретной конфигурации и типа выполняемых операций.

https://www.chabad.org/library/article_cdo/aid/7288064/jewish/Can-I-Let-My-AI-Agent-Run-on-Shabbat.htm

Наверное все уже видели :)

https://youtu.be/b34vwOWLDXI?is=w6CgC0s6qXXfJH9I

First Principles Thinking

Короткое эссе Sunil Sadasivan — отклик на пост «the senior engineer death spiral». Главная мысль: опыт сеньора сам становится тормозом — прошлые проекты и знакомые ограничения решают задачу ещё до того, как она понята. Лекарство — мышление от первых принципов: «положить опыт в коробку», отложить его и заново спросить, что мы делаем, зачем это людям и как связаны части. Лучшие инженеры, с которыми работал автор (часто из поддержки, дизайна, self-taught), связывали код с происходящим вне кода и потому держали решения простыми.

Вторая часть — про agentic-разработку: легче всех входят те, кто уже так думает — признают, что многого не знают, и пробуют, вместо того чтобы считать старое ограничение всё ещё действующим. С AI начинать надо не с технологии, а с вопроса «что мы пытаемся сделать и чем тут поможет AI». Это даёт momentum: понимая цель, делаешь маленький шаг, учишься на нём, идёшь дальше — а с агентами такие циклы обучения крутятся заметно быстрее. Это автор и называет новым flow state.

Long Live Human Thinking.

https://sunilsadasivan.com/writing/first-principles-thinking/

DHH: конец ручного программирования?

В докладе на Rails World 2026 DHH утверждает, что ИИ-агенты уже радикально изменили разработку. В 37signals объявили «pencils down»: вручную код теперь пишут лишь в исключительных случаях. Роль разработчика смещается к постановке целей, архитектуре, управлению агентами и проверке результата. При этом DHH не хоронит Rails: соглашения, компактность и ориентация на одного разработчика хорошо подходят агентной эпохе. HEY становится экспериментом нового подхода — нативные клиенты и backend на Rust, создаваемые агентами. Главный вывод: не бояться перемен, а осваивать новый способ создавать продукты.

5 ключевых цитат:

1. “We have gone pencils down on the idea that we were gonna write code by hand.”
2. “English is a better programming language than Ruby.”
3. “I have retired from being a professional programmer.”
4. “Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers.”
5. “On the other side of that is a new career… as a professional maker of things.”

Rails World 2026 Opening Keynote — DHH

Operational Ontology — простой подход к безопасным ИИ-агентам.

ИИ разрешают искать данные, сравнивать варианты и предлагать действия, но не дают напрямую менять важные данные. Каждое изменение проходит через отдельное действие с жёсткими правилами в обычном коде. Например, агент может попросить отменить заказ, но система не позволит отменить уже отправленный — независимо от промпта. Все успешные и отклонённые попытки записываются в журнал.

То есть ИИ отвечает за гибкое рассуждение, а критичные решения и ограничения — за проверяемый код.

https://github.com/gura105/operational-ontology

Plan Advice in PostgreSQL 19

PostgreSQL 19 добавляет функцию Plan Advice, которая анализирует планы выполнения запросов и предлагает оптимизации. Система автоматически выявляет неэффективные индексы, неправильные статистики и другие проблемы производительности, помогая разработчикам улучшить скорость работы баз данных без глубокого знания внутреннего устройства оптимизатора.

https://tapoueh.org/blog/2026/09/plan-advice-in-postgresql-19/

Oleg Bartunov

Исследователь обучил 4-миллиардную модель генерировать планы запросов на 81% быстрее, чем стандартный PostgreSQL. Подход использует обратную связь от базы данных — информацию о выбранных и отклонённых путях выполнения — чтобы снизить слепой поиск и затраты на обучение. Автор видит будущее в специализированных моделях, встроенных в конкретные системы и работающих в партнёрстве с человеком.

https://www.linkedin.com/feed/update/urn:li:activity:7506559458664275968/

Суть поста Кента Бека: у разработки два измерения, а меряют обычно одно. Первое — поведение (фичи, которые система уже умеет), его легко посчитать. Второе — структура, или ось «futures» на диаграмме, сделанной с Джином Кимом: множество того, что вы сможете сделать дальше. В комментариях Бек уточняет: если «джинн» (ИИ) пишет код неустойчивым способом, вариантов следующих шагов становится всё меньше; улучшение структуры системы, наоборот, расширяет пространство возможных будущих.

Почему это важно: ИИ сделал ось «поведение» почти бесплатной, но по оси «структура» счёт не оплачивается — он берётся в кредит. Команда шипит кратно больше, а через несколько месяцев каждое изменение стоит дороже: код есть, понимания системы и свободы манёвра нет. Вывод тот же, что в «Tidy First?»: вложения в структуру — это покупка будущих опций, и именно они определяют, сохранится ли скорость разработки.

https://www.linkedin.com/feed/update/urn:li:activity:7505615017212387329/

Kent Beck

Разработчик должен начинать задачу, имея достаточно информации для старта, а не ждать полной информации для завершения. Полной информации не существует. Знания приходят в процессе работы.

https://www.linkedin.com/feed/update/urn:li:activity:7505344578716094465/

Trey Kauffman

В 2001 году австралийский патентный поверенный Джон Майкл Кеог запатентовал колесо, чтобы продемонстрировать несостоятельность новой системы патентования в Австралии, которая выдавала патенты после проверки только формальностей без экспертизы новизны. За это он получил Шнобелевскую премию в 2001 году, а Австралия впоследствии отменила такой тип патентов. Патент — это не подтверждение новизны или работоспособности изобретения, а лишь документ, прошедший формальную проверку.

https://www.linkedin.com/feed/update/urn:li:activity:7504726775768322048/

Tell HN: OpenAI keeps re-enabling the 'allow training' setting

Пользователь обнаружил, что OpenAI повторно включает настройку разрешения на использование данных для обучения моделей, несмотря на то, что он её отключал несколько раз. Он рекомендует проверить эту опцию в своих настройках, так как она может быть переактивирована без ведома пользователя.

https://news.ycombinator.com/item?id=49643556

WalShadow: репликация Postgres → ClickHouse из физического WAL, ~200 мс

ClickHouse открыл исходники WalShadow — движка, который реплицирует Postgres в ClickHouse не через логическую репликацию, а прямо из физического WAL (того же потока, что читает physical standby).

Как устроено: каталожные WAL-записи проигрываются в «теневой» Postgres только со схемой, heap-записи параллельно декодируют Rust-декодеры, батчер собирает нативные блоки ClickHouse, пул инсертеров пишет их конкурентно. Ни output-плагина логического декодирования, ни Kafka, ни JSON. Блоки могут приходить не по порядку, поэтому к каждой строке цепляется _lsn, и ClickHouse оставляет свежую версию ключа; схемные изменения и TRUNCATE идут через барьеры.

Цифры (c8i.2xlarge, 8 vCPU, один регион, одна таблица): commit→видимость ~200 мс против ~50 мс у физической реплики Postgres и ~10 с у PeerDB. Пропускная: источник ~290K строк/с, WalShadow 289K/с, PeerDB ~120K/с.

Главное практически: нагрузка на источник как у обычного physical standby, слоты логической репликации не нужны; поддержаны initial load, эволюция схемы (ADD/RENAME/DROP COLUMN, CREATE TABLE), восстановление после рестарта и плановый switchover. Оговорка: бенчмарк синтетический, продакшн-закалка с design-партнёрами ещё идёт.

https://clickhouse.com/blog/introducing-walshadow