Postgres Pro 16 beta под нагрузкой: тестируем на клиенте, уходящем с Oracle

У нас сейчас идёт один из самых объёмных Oracle-to-Postgres переездов за последнее время. Клиент - из регулируемого сегмента, требования к импортозамещению ПО давят сверху, сроки поджимают. Основной выбор пал на Postgres Pro: сертификат ФСТЭК, российский вендор, совместимость с политиками закупок. Мы ведём managed-сопровождение этого стека, и когда в июне вышла публичная бета Postgres Pro 16, решили не ждать GA и сразу посмотреть, что там реально изменилось - прямо на нагрузке клиентского стейджинга.

Это не обзор релиза. Это рабочие наблюдения за пару недель с бетой.

Контекст: откуда идём

Oracle 19c, OLTP-нагрузка с несколькими сотнями таблиц, несколько аналитических витрин, которые питаются через потоковую репликацию от основного кластера. Схема уже портирована на PG 15 - это была отдельная многомесячная история с конвертацией типов, переписыванием пакетов и ещё одним кругом ада с sequences. На стейджинге живёт нагрузочный стенд, который гоняет синтетику, примерно воспроизводящую боевой профиль.

На этот стенд и встала Postgres Pro 16 beta.

Logical replication: что изменилось и почему нам это важно

В 16-й версии апстрим PostgreSQL серьёзно доработал логическую репликацию. Два момента, которые нас интересовали больше всего:

Параллельное применение изменений на подписчике. До 16-й большие транзакции применялись на реплике последовательно - один воркер, один поток. Теперь можно выставить max_parallel_apply_workers_per_subscription и репликация начинает нагонять отставание заметно быстрее. Мы проверили на тесте с симуляцией массовой загрузки: при прогоне пакетной вставки в несколько параллельных сессий на паблишере реплика в PG 15 начинала отставать и нагоняла с задержкой. На Pro 16 beta при тех же параметрах нагрузки лаг оставался значительно меньше. Цифры не приводим - бета, стенд синтетический, но качественная разница ощутима.

Фильтрация по строкам и столбцам в публикациях. Это появилось частично ещё в PG 15 (row filtering), теперь добавилась фильтрация по столбцам. Для нашего кейса это позволило вынести аналитические витрины в отдельные публикации без таблиц-прослоек: указали нужные колонки прямо в CREATE PUBLICATION ... FOR TABLE t (col1, col2, col3). Убрали одну лишнюю прослойку, WAL-трафик на реплику стал заметно скромнее.

Оба улучшения для сценария «основной кластер + аналитическая реплика» - это именно то, чего не хватало.

pg_stat_io: новый взгляд на I/O

Одно из нововведений, на которое я бы особо обратил внимание - новое системное представление pg_stat_io. В предыдущих версиях понять, куда именно уходит I/O, было задачей для iostat плюс ручной корреляции с pg_stat_bgwriter и pg_stat_database. Это работало, но требовало опыта и терпения.

pg_stat_io даёт детализацию по типам операций (read, write, extend, fsync) в разрезе backend_type и context (normal, bulkread, bulkwrite, vacuum). Фактически можно увидеть, кто и как генерирует нагрузку на диск: обычные бэкенды, autovacuum, bgwriter, checkpointer - отдельно по каждому.

На нашем стенде это сразу помогло: autovacuum на нескольких горячих таблицах генерировал неожиданно много extend-операций. Без pg_stat_io мы бы нашли это гораздо дольше. Это просто хороший инструмент диагностики, который давно нужен был в ядре.

Что оказалось сырым

Несколько вещей, которые в бете ведут себя не так, как хотелось бы.

Совместимость расширений. Часть расширений, которые мы используем, в Pro 16 beta ещё не готова под новый API. pg_partman нужен был конкретной версии, которая появилась буквально на днях. Это нормально для беты, но планировать переезд надо с запасом.

Параметр enable_group_by_reordering. В 16-й добавили оптимизатор GROUP BY reordering - в теории должно ускорить агрегаты. На нескольких аналитических запросах с нашего стенда план изменился, и в паре случаев - не в лучшую сторону. Пришлось явно отключить на уровне сессии. Проблема воспроизводимая, логируем, чтобы проверить в RC.

Документация по Postgres Pro-специфичным фичам. Это не претензия к апстриму, но часть Postgres Pro-надстроек в бете опережает документацию. Несколько параметров нашли только в исходниках.

Где мы сейчас

GA PostgreSQL 16 ожидается осенью, Postgres Pro 16 - примерно тогда же. До тех пор мы остаёмся на PG 15 в продакшне и продолжаем гонять 16 beta на стейджинге - логируем отклонения, следим за RC.

Для клиентов, мигрирующих с Oracle, улучшения в логической репликации - это реальный аргумент в пользу 16-й версии, а не просто маркетинг в патчноутах. Параллельное применение изменений на реплике и column-level filtering в публикациях закрывают сценарии, которые в 15-й приходилось обходить костылями.

Если ваша задача - перевести боевой Oracle-кластер на Postgres Pro с минимальным окном обслуживания, наблюдения с нашего стенда могут быть полезны. Работаем в рамках managed-сопровождения.