PostgreSQL 19 Beta обещает добраться до стабильного релиза в сентябре 2026 года, а пока уже показывает набор изменений, который интересен не только любителям новых фич, но и людям, отвечающим за прод. В бете появились нативные графовые запросы SQL/PGQ, онлайн-упаковка таблиц без остановки сервиса и серия оптимизаций, которые бьют по самым болезненным местам: простои, vacuum, репликация и поведение планировщика.
Как пишет InfoQ, ежегодный осенний релиз PostgreSQL в этот раз идет не по пути «еще немного синтаксиса», а закрывает сразу два давних класса задач. Первый связан с тем, что команды все чаще хотят запускать графовую аналитику поверх уже существующих реляционных данных, не поднимая отдельную графовую СУБД и не мигрируя модель. Второй — с рутинной, но дорогой эксплуатацией: таблицы раздуваются, место нужно возвращать, а окно простоя никто не дает. Для российских команд, которые держат продуктовые базы под высокой нагрузкой и живут в режиме ограниченных инфраструктурных бюджетов, это как минимум повод поставить бету в стенд и внимательно посмотреть на roadmap миграции.
Главная витринная новинка — поддержка SQL Property Graph Queries, или SQL/PGQ. По сути, PostgreSQL 19 Beta дает возможность выполнять графовые запросы поверх уже существующих реляционных таблиц. Это важный разворот: раньше похожие сценарии часто упирались в выбор между сложными self-join-конструкциями, отдельным графовым движком или выгрузкой данных в стороннюю систему. Теперь PostgreSQL пробует забрать часть этой работы себе. Для команд, которые строят рекомендательные механики, анализируют связи между пользователями, устройствами, транзакциями или сущностями каталога, это выглядит как шанс сократить архитектурный зоопарк. Не везде графовые запросы заменят специализированные решения, но во многих внутренних кейсах идея «сделать это прямо в Postgres» звучит достаточно привлекательно, чтобы ее хотя бы проверить.
Не менее заметная вещь для операционной команды — новый REPACK с опцией CONCURRENTLY, то есть фактически онлайн-пересборка таблиц для возврата места без блокирующего простоя. На бумаге это выглядит куда менее гламурно, чем графы, но в реальной эксплуатации именно такие функции экономят больше нервов, чем красивый синтаксис на конференционных слайдах. В ту же корзину идут параллельный autovacuum, более умная приоритизация vacuum-задач и автоматическое отслеживание видимости страниц, которое должно уменьшить потребность в будущих проходах vacuum. Отдельно PostgreSQL 19 Beta развивает асинхронный I/O, появившийся в версии 18: теперь система умеет автоматически масштабировать число I/O-воркеров. Если перевести это с языка release notes на язык SRE и DBA, посыл простой: база должна меньше мешать сама себе под нагрузкой и реже требовать ручных костылей вокруг обслуживания.
Производительность и планировщик: меньше сюрпризов, больше контроля
Разработчики PostgreSQL отдельно подчеркивают производительность как один из фокусов релиза. Самая броская цифра — до 2x лучшая производительность вставок в сценариях, где есть проверки внешних ключей. Для систем с тяжелым write-path это уже не косметика. Плюс к этому в релизе доработаны планировщик и executor: появились новые оптимизации anti-join, расширилось использование incremental sort, добавлена eager aggregation для ускорения обработки строк, ускорено чтение со storage при parallel sequential scan. Даже на уровне выражений есть прагматичная мелкая оптимизация: конструкции IS DISTINCT FROM и IS NOT DISTINCT FROM в случаях, когда входные данные не допускают NULL, могут упрощаться до обычных операторов <> и =. Для бизнеса это не звучит как headline, зато для команды, которая раз в квартал ловит деградацию в сложной аналитической выборке, именно такие детали потом определяют, сколько часов уйдет на разбор плана запроса.
Вокруг планировщика появилась и новая степень управляемости. PostgreSQL 19 Beta добавляет расширения pg_plan_advice и pg_stash_advice, которые помогают управлять решениями планировщика и сохранять их. Это явно ответ на старую боль продакшн-команд: хороший план запроса сегодня не гарантирует хороший план завтра, особенно после обновления статистики, смены версии или роста объема данных. Здесь важно не переоценить новинку: она не отменяет необходимости понимать собственные запросы и схему. Но для компаний, где база обслуживает десятки сервисов и цена непредсказуемого replanning слишком высока, дополнительный контроль выглядит полезнее, чем очередной спор о том, «почему Postgres сам не догадался».
Отдельный пласт изменений касается репликации и событийной нагрузки. Logical replication теперь автоматически синхронизирует значения sequence, так что при крупных апгрейдах меньше шансов получить ручную сверку и дополнительные скрипты на ровном месте. Включать logical replication можно без перезапуска сервера, а это уже прямое сокращение плановых окон обслуживания. Плюс есть улучшения масштабируемости LISTEN/NOTIFY для многоканальных нагрузок. А основатель и CEO ProxySQL Рене Каннао отдельно выделил функцию WAIT FOR LSN: по его словам, она убирает массу неустойчивых бэкенд-обходов, когда после записи приложение либо искусственно ждет, либо насильно отправляет read-after-write обратно на primary. В PostgreSQL 19 реплика сможет нативно приостановить сессию, пока не догонит нужную точку WAL. Для систем, где чтение с реплик смешано с жесткими требованиями к консистентности, это один из самых практичных апдейтов всего релиза.
Почему операторов волнуют не графы, а тихие изменения
Реакция сообщества на PostgreSQL 19 Beta показательная: headline-фича про графовые запросы заметна всем, но опытные операторы смотрят на менее рекламные изменения. CEO PGX Кристоф Петтус обратил внимание, что на поведение production-систем сильнее могут повлиять не графы, а «тихое» переключение jit = off по умолчанию. Для части аналитических нагрузок это изменит планы запросов и время выполнения — в лучшую или худшую сторону, в зависимости от конкретного профиля. Он же отметил переход на 64-битный MultiXactOffset, который убирает риск wraparound на уровне 4 миллиардов участников — проблема нишевая, но для очень загруженных сценариев с множественными блокировками строк вполне реальная. Параллельно облака не ждут финального релиза: AWS уже выложила Beta 1 в RDS Database Preview Environment для управляемого тестирования. На фоне этого экосистема тоже шевелится: появился PGQViewer, open source-инструмент для исследования графов в PostgreSQL 19, а Марк Каллаган после своих бенчмарков на небольшом сервере сформулировал, пожалуй, лучший комплимент для зрелой СУБД: Postgres остается «скучным в хорошем смысле», и заметные регрессии в нем по-прежнему трудно найти.
Для рынка это выглядит так: PostgreSQL продолжает расширяться не в ширину ради галочки, а в сторону все более плотного покрытия соседних задач. Сначала база научилась увереннее работать как платформа для JSON, потом прибрала к себе все больше аналитических и репликационных сценариев, а теперь подбирается к графовым запросам и одновременно чинит старые операционные боли. Вопрос уже не в том, сможет ли PostgreSQL 19 Beta собрать внимание сообщества, а в том, сколько команд после релиза в сентябре решат, что отдельный графовый стек, самодельный repack-процесс или хрупкая логика read-after-write им больше просто не нужны. Проверить, насколько амбиции беты совпадают с реальностью, можно по исходному разбору InfoQ .
The post PostgreSQL 19 Beta добавила графовые SQL-запросы и онлайн repack appeared first on iTech News.