PostgreSQL 14 завершит поддержку в ноябре 2026 года: обновляться до 17 или 18?

На официальной странице жизненного цикла для PostgreSQL 14.24 указана дата окончания поддержки — 12 ноября 2026 года. Для большинства производственных систем разумно сначала оценить переход на PostgreSQL 17: так команда может поставить совместимость приложений и расширений выше потребности в новейших функциях. PostgreSQL 18 стоит выбирать, если совместимость проверена на целевой сборке и конкретная функция этой версии нужна рабочей нагрузке. Миграцию следует начать до даты окончания поддержки, а конечный выбор сделать по результатам репетиции.

Материал предназначен для DBA, отвечающих за жизненный цикл и согласование изменений в системах на PostgreSQL 14. Он также будет полезен разработчикам и руководителям SaaS-команд, которым нужно оценить риск миграции до утверждения окна работ.

Последнее обновление: 21 октября 2026 года. Даты поддержки и сведения о целевых версиях сверены с официальной страницей жизненного цикла PostgreSQL и документацией к выпускам PostgreSQL 18.

Решение по версии зависит от срока поддержки, совместимости и изменений

Срок поддержки важен, но сам по себе он не определяет целевую версию. По опубликованному графику, PostgreSQL 17.11 поддерживается до 8 ноября 2029 года, а PostgreSQL 18.6 — до 14 ноября 2030 года (официальный график версий). Версия 18 даёт более длительный период сопровождения, однако для системы, где расширения или драйверы ещё не проверены, этот запас не снимает риск миграции.

Зафиксируйте четыре параметра решения до выбора:

• Срок поддержки. Сколько времени останется до следующего планового перехода после внедрения целевой версии? Сопоставьте жизненный цикл версии с внутренним календарём изменений.
• Совместимость. Подтверждены ли поддержка целевой версии у всех расширений, драйверов, приложений, средств резервного копирования и мониторинга?
• Риск переключения. Какой простой допустим, есть ли проверенный план возврата и можно ли сохранить исходный экземпляр до завершения проверки?
• Практическая ценность новшеств. Нужна ли конкретная возможность PostgreSQL 18 именно этой системе или выбор новой версии пока основан только на её новизне?

Релиз PostgreSQL 18 опубликован 25 сентября 2025 года; сведения о выпусках и изменениях этой основной версии доступны в официальных примечаниях к выпуску. На дату проверки актуальными поддерживаемыми выпусками, указанными в графике для сравнения, являются 17.11 и 18.6. Это номера обновлений внутри веток, а не альтернативные основные версии: при подготовке плана нужно отдельно выбрать основную версию и затем установить актуальный доступный для неё выпуск с исправлениями.

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

Можно ли оставить PostgreSQL 14 после окончания поддержки?

Технически база не обязана перестать запускаться в день завершения поддержки. Но продолжение эксплуатации после 12 ноября 2026 года означает работу за пределами опубликованного периода сопровождения этой версии (график жизненного цикла PostgreSQL). Поэтому это не нейтральный способ «отложить решение»: организация принимает на себя отдельный риск, который нужно явно зарегистрировать и согласовать.

Если перейти до даты поддержки невозможно, оформите временный план исключения, а не бессрочное продление текущего состояния. В нём укажите ответственного, причину отсрочки, меры защиты, дату пересмотра и критерии, по которым миграцию можно считать готовой. Ограничьте изменения схемы и расширений, если они усложняют дальнейший переход; отдельно проверьте, что резервные копии восстанавливаются в изолированной среде. Наличие копии без успешной проверки восстановления не подтверждает готовность к аварии.

При этом оставаться на PostgreSQL 14 после окончания сопровождения не следует считать стратегией обновления. Параллельно должны идти проверка приложений, оценка пути миграции и репетиция восстановления. Если обнаружен блокирующий фактор — например, несовместимое расширение, — сначала найдите подтверждённый вариант обновления этого компонента или спланируйте замену. Не превращайте календарную дату в единственный критерий: безопаснее заранее согласовать временный период ограничения риска, чем переключить производственную систему без проверенного возврата.

Совместимость: какие компоненты проверить перед выбором PostgreSQL 17 или 18

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

Составьте инвентаризацию как минимум по следующим группам:

• Расширения базы данных. Для каждого расширения установите точную версию, наличие сборки для выбранной основной версии и порядок обновления. Проверьте зависимости от библиотек ОС, процедурных языков и привилегий.
• Клиентские драйверы и библиотеки. Зафиксируйте версии драйверов в приложениях и фоновых службах; отдельно проверьте параметры TLS, аутентификацию, обработку ошибок и повторные подключения.
• Пулы соединений и промежуточное ПО. Испытайте реальные режимы работы, включая транзакции, подготовленные запросы, сброс соединений и ограничения пула.
• Операционная система и пакеты. Проверьте доступность пакетов целевой версии, зависимости и сценарии установки на том выпуске ОС, который будет использоваться в эксплуатации.
• Эксплуатационные инструменты. Подтвердите работу мониторинга, агента резервного копирования, экспорта метрик, миграций схемы, восстановления и регламентных заданий.
• Приложение и запросы. Запустите автоматические тесты и сценарии, которые затрагивают критичные транзакции, отчёты, блокировки и обработку больших результатов.

Для PostgreSQL 18 сверяйте переходные ограничения с примечаниями к выпуску 18.6 и общими примечаниями к выпуску PostgreSQL 18. Упоминание компонента в одном успешном отчёте или форуме не подтверждает совместимость другой его версии, сборки или конфигурации. Официальные примечания помогают обнаружить изменения поведения, но не заменяют проверку конкретного приложения и комплекта расширений.

Когда проверка склоняет выбор к PostgreSQL 17, а когда — к PostgreSQL 18

Используйте условия как рабочий фильтр; если хотя бы одна обязательная проверка не пройдена, не утверждайте дату переключения до устранения блокера.

• Если расширение или драйвер не подтверждает работу с PostgreSQL 18, а для PostgreSQL 17 есть поддерживаемая сборка, выбирайте 17 либо сначала согласуйте обновление компонента. Не предполагайте, что совместимость с одной веткой автоматически переносится на другую.
• Если все критичные компоненты проверены на PostgreSQL 18 и системе действительно нужна функция этой версии, выбирайте 18, но только после полного прогона миграции, тестов приложения и восстановления.
• Если обе версии подходят, а новая функция не входит в требования, сначала сравните внутренний график обслуживания и объём изменений. PostgreSQL 17 может быть более консервативным целевым шагом для команды, которая ставит управляемость изменений выше более длительного окна поддержки.
• Если ни одна версия не прошла проверки, не переключайте производство ради формального соблюдения календаря. Зафиксируйте риск работы на старой версии и устраните конкретные препятствия в отдельном плане.
• Если тестовый результат не воспроизводится на конфигурации, близкой к производственной, решение остаётся предварительным. Повторите испытания с теми же расширениями, настройками и данными, которые важны для эксплуатации.

Маршрут миграции выбирают по допустимому простою и плану возврата

Основное обновление — не замена исполняемых файлов. Это перенос кластера с проверкой формата данных, настроек, расширений, приложений и процедур запуска. В официальной документации описаны разные подходы; выбор зависит от объёма данных, доступного места, нагрузки и того, можно ли организовать параллельную работу старого и нового экземпляров.

Официальное руководство описывает проверки и применение pg_upgrade; общие варианты перехода собраны в документации по обновлению. Для логической репликации следует отдельно изучить официальный сценарий обновления: наличие репликации не означает, что все объекты и операции автоматически переносятся этим способом.

Нельзя обещать конкретную продолжительность простоя только по названию инструмента. Она зависит от размера и состояния кластера, скорости чтения и записи, выбранного пути, количества объектов, расширений и времени на проверки. Измерьте процесс на копии данных или репрезентативном стенде; зафиксируйте отдельно длительность переноса, финальной синхронизации, валидации и принятия решения о переключении.

Сколько будет длиться простой при pg_upgrade?

Сам pg_upgrade не задаёт универсального времени простоя: фактическое окно определяется параметрами кластера и тем, какие операции включены в согласованный план переключения. Оценивать его по размеру базы без пробного запуска ненадёжно. Включите в измерение остановку записи, подготовку, проверки, запуск служб, тесты приложения и решение о продолжении.

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

Важно: откат после того, как новая версия приняла производственные записи, нельзя считать простым запуском старого кластера. До переключения определите, как будут обработаны новые данные при отмене работ, и каким способом сохраняется согласованность.

Пошаговый план: от инвентаризации до решения о переключении

Первый этап: зафиксируйте исходное состояние

Сохраните версию сервера, параметры запуска, конфигурационные файлы, список баз и владельцев, роли, привилегии и используемые расширения. Выгрузите текущие метрики нагрузки и выделите запросы, для которых регрессия недопустима. Не храните описание единственной конфигурации только в памяти администратора: оно понадобится при сравнении тестового и производственного кластера.

Второй этап: выберите кандидатов и проверьте поддержку компонентов

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

Третий этап: выберите путь и проверьте резервную копию

Сравните pg_upgrade, логическое восстановление и репликацию по требованиям к простою, времени подготовки и доступному сценарию возврата. Проверьте, что копия находится отдельно от производственного хранилища, и восстановите её в изолированной среде. Сверьте целостность данных и доступность приложения после восстановления; инструкции по вариантам копирования и восстановления приведены в руководстве PostgreSQL по резервному копированию.

Четвёртый этап: проведите репетицию и измерьте окно

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

Пятый этап: оформите критерии продолжения и возврата

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

Шестой этап: переключите систему и завершите наблюдение

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

Ресурсы и защита данных проверяются по нагрузке, а не по названию версии

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

Проверьте отдельные сценарии отказа: что произойдёт при повреждении диска, неудачном обновлении ОС или потере производственного узла. Если накопители используются без аппаратного RAID, предусмотрите программное зеркалирование или репликацию и не считайте их заменой резервной копии. Копии следует хранить вне основного узла и периодически проверять восстановлением. Состав узла, объём памяти, накопителей и доступные операционные системы следует подтверждать по фактической конфигурации площадки, а не выводить из версии PostgreSQL.

Если рассматривается аренда выделенного сервера для самостоятельно управляемой базы, сначала сопоставьте её с текущей платформой по изоляции вычислительных ресурсов, доступу к дисковой компоновке, стоимости и объёму операционной работы. Общая виртуальная среда может быть удобна для небольших или кратковременных нагрузок, но характеристики дисков и вычислительных ресурсов зависят от конкретного предложения; их нужно проверять по условиям тарифа. Для длительной базы с предсказуемой нагрузкой имеет смысл отдельно оценить вариант с выделенным узлом, особенно если текущая инфраструктура ограничивает контроль над размещением данных или расходами. Фактические доступные варианты CloudUDP приведены на странице тарифов и конфигураций.

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