Postgres 16 против 17 против 18: выигрыш, который имеет значение

Три версии не отличаются единым общим показателем производительности. Каждый из них исправляет определенный момент архитектуры, каждый раз для разной аудитории: большие таблицы для Postgres 17, хранилище с высокой задержкой для Postgres 18. В таблице ниже обобщаются проверяемые факты, все датированные, прежде чем углубляться в детали каждого проекта.

Источники: официальные примечания к выпуску проекта PostgreSQL (postgresql.org), перекрестные ссылки на анализы, опубликованные Microsoft Tech Community и Crunchy Data после каждого основного выпуска. По состоянию на 24 августа 2026 г.

До версии Postgres 17 VACUUM хранил список мертвых кортежей для очистки в простом массиве размером maintenance_work_mem. Проблема была не в скорости расчета, а в самой структуре: эта таблица стабильно занимала около 1 ГБ, сколько бы сверх этого ни настраивалось. В таблице с более чем 178 миллионами мертвых строк VACUUM пришлось выполнить несколько проходов, каждый из которых перечитывал все индексы.

Postgres 17 заменяет этот массив структурой под названием TidStore, адаптивным базовым деревом, которое сильно сжимает пространство, необходимое для хранения идентификаторов кортежей. Официальные примечания к выпуску проекта указывают на сокращение памяти, используемой VACUUM, в некоторых случаях до 20 раз, без искусственного потолка, связанного со старой конструкцией. Источник: официальные примечания к выпуску PostgreSQL 17, postgresql.org, 26 сентября 2024 г. Microsoft Tech Community и Crunchy Data опубликовали технический анализ этого изменения вскоре после выпуска. Оба подтверждают конкретный интерес к таблицам из нескольких сотен миллионов строк с высокой частотой удаления или обновления.

Этот проект в основном приносит пользу конкретному сценарию: большая таблица с высокой частотой удаления или обновления. Раньше VACUUM выполнялся в несколько проходов из-за нехватки доступной памяти. На маленьком столе или при нагрузке преимущественно чтения выигрыш остается незначительным или даже невидимым.

Второй проект Postgres 17 затрагивает более деликатный момент: расчет снимков транзакций. Каждый запрос должен знать, какие еще транзакции выполняются, чтобы обеспечить соблюдение правил видимости MVCC Postgres. На машине с большим количеством ядер и активных соединений этот расчет вызвал разногласия по поводу общей внутренней структуры. Это узкое место, которое уже давно документировано участниками проекта.

Postgres 17 уменьшает это противоречие. Эффект в основном измеряется на экземплярах с высоким уровнем параллелизма и множеством одновременных активных подключений на многоядерном оборудовании. При низкой нагрузке параллелизма разница с Postgres 16 остается незначительной: это проект масштабируемости, а не уменьшение задержки на изолированный запрос.

Этот выигрыш не заменяет пул соединений, а просто снижает его внутреннюю стоимость. Если количество активных подключений уже является вашим узким местом, основная версия отходит на второй план. В нашем руководстве по настройке max_connections и в нашем сравнении режимов транзакций PgBouncer этот вопрос рассматривается более подробно.

Postgres 18, выпущенный в конце сентября 2025 года, решает более структурную проблему. До этого каждое чтение диска Postgres блокировало запрашивавший его процесс. Новая подсистема асинхронного ввода-вывода (AIO) позволяет процессу инициировать несколько операций чтения параллельно и продолжать работу до их завершения, вместо того, чтобы последовательно ждать каждого из них.

Параметр io_method управляет этим поведением: worker (процессы, предназначенные для ввода-вывода, по умолчанию) или io_uring в Linux, если Postgres был скомпилирован с этой поддержкой. Последовательное сканирование, сканирование кучи растровых изображений и VACUUM — первые преимущества, особенно в хранилищах с высокой задержкой: сетевых дисках, облачных томах, а не локальном NVMe.

PlanetScale, предлагающая управляемое предложение Postgres, опубликовала собственное сравнение Postgres 17 и 18, ориентированное на это изменение ввода-вывода. Это их измерения на собственной инфраструктуре, а не цифры, которые мы воспроизвели здесь независимо. Воспринимайте это как сигнал о том, что предмет стоит тестировать на реальной нагрузке, а не в универсальном проценте.

Обобщенный AIO Postgres 18 продолжает проект, начатый в Postgres 17, а не является изолированным изменением. Версия 17 уже представила интерфейс потокового ввода-вывода, но ограничивалась АНАЛИЗОМ и последовательным сканированием. Postgres 18 расширяет ту же логику для более широкого спектра операций, включая VACUUM и сканирование кучи растровых изображений. Таким образом, две версии воспринимаются как прогресс, а не как две отдельные ставки на ввод-вывод.

Заслуживают внимания еще три изменения в Postgres 18, даже если они напрямую не касаются производительности.

Пропуск сканирования в индексе B-дерева с несколькими столбцами позволяет Postgres использовать составной индекс, даже если запрос не фильтрует его головной столбец. До версии Postgres 18 этот сценарий часто требовал полного сканирования таблицы или создания дополнительного выделенного индекса.

Созданные виртуальные столбцы (GENERATED ALWAYS AS (...) VIRTUAL) становятся поведением по умолчанию, если STORED не указан. Виртуальный столбец рассчитывается при чтении, а не при записи на диск, что уменьшает объем записи каждый раз, когда исходная строка вставляется или обновляется.

В Postgres 18 наконец добавлена ​​поддержка OAuth 2.0 на стороне аутентификации (RFC 8628, поток устройств), наряду с существующими механизмами, такими как SCRAM, сертификаты или LDAP. Актуальный момент для любой организации, которая уже централизует свои удостоверения через внешнего поставщика OAuth/OIDC.

В Aurabase база данных клиентов в настоящее время работает в Postgres 16.15, а не 17. Это можно проверить непосредственно в репозитории: эталонный образ CNPG (docker/Postgres.CNPG.Dockerfile) начинается с ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm, закрепленного дайджестом, той же основной версии, что и общий уровень (docker/Postgres.Dockerfile). Проверено 24 августа 2026 г.

Кодекс также документирует, почему. Комментарий к исправлению в k8s_tenant.rs объясняет, что более ранний резервный вариант ошибочно указывал на postgresql:17.2. Причина, указанная в то время: стандартное изображение не будет включать pgvector, при проверке оказалась ложной. Оба изображения имеют pgvector: 0.8.0 в 17.2, 0.8.5 в 16-standard-bookworm, измеренном на кластере флота.

Реальный риск, описанный в самом комментарии, заключается в другом: CloudNativePG запрещает любое понижение основной версии после создания кластера. Парк, подготовленный по ошибке в Postgres 17, будет необратимым, тогда как все, что было проверено сквозной проверкой в ​​Aurabase, было в Postgres 16.

// Основная версия сохраняется, если TENANT_POSTGRES_IMAGE не определен.
let repli = "ghcr.io/cloudnative-pg/postgresql:16-standard-bookworm";

tracing::warn!(
    image = repli,
    "TENANT_POSTGRES_IMAGE non défini : repli sur la version validée."
);

Это не приговор Postgres 17 как таковому. Это политика эксплуатационной осмотрительности: не переводите производственный парк на основную версию до тех пор, пока не будет проведена сквозная проверка. Те же рассуждения применимы к любой команде, которая управляет Postgres через CloudNativePG или эквивалентного оператора Kubernetes. Вопрос не только в ожидаемом приросте производительности, но и в пути назад, если что-то пойдет не так.

Стоит ли вам перейти на Postgres 17 или 18 сейчас?

Три критерия позволяют принять решение, не дожидаясь универсальной цифры. Во-первых, размер и скорость изменения ваших самых больших таблиц: если VACUUM уже выполняется в несколько проходов, рабочий сайт памяти Postgres 17 применяется непосредственно к вашему случаю. Затем ваше хранилище: на локальном SSD с низкой задержкой асинхронный ввод-вывод Postgres 18 обеспечивает меньше, чем на сетевом томе. Наконец, ваш путь назад: для оператора, который запрещает существенное понижение версии, тестирование сначала на одноразовой среде не является дополнительной мерой предосторожности.

Конкретно, то же правило применяется к любому парку, управляемому оператором Kubernetes. Сначала подготовьте тестовый кластер в целевой версии, а затем воспроизведите на нем репрезентативную для вашей рабочей версии нагрузку. Прикасайтесь к реальному кластеру только после полной проверки этого теста, а не только после прочтения примечаний к выпуску. Если ваше решение также касается выбора между выделенной базой и общей базой для принятия такого типа изменений, наша статья выделенная и общая база исследует этот аспект.

Выбор между Postgres 16, 17 и 18 заключается не только в том, какая версия «самая быстрая». Postgres 17 устраняет реальную структурную проблему VACUUM в больших таблицах и уменьшает конфликты при высоком уровне параллелизма. Postgres 18 идет дальше с асинхронным вводом-выводом — архитектурным изменением, которое требует тестирования на фактической нагрузке и хранилище, прежде чем его обобщать.

Критерием, который чаще всего забывают, является не производительность, а обратимость. У такого оператора, как CloudNativePG, обновление основной версии не отменяется постфактум. Прежде чем переключать производственный парк, реальный вопрос заключается не только в ожидаемой выгоде, но и в пути возврата, если испытание не пройдено. Если вы готовитесь к обновлению этой версии, в нашем контрольном списке настройки Postgres в рабочей версии подробно описаны настройки, которые необходимо проверить после основного изменения версии.