PostgreSQL 14 перестаёт получать исправления: как обновить базу без потери данных

Пошаговая стратегия миграции для тех, кто отвечает за критичную базу данных

PostgreSQL 14 получит последний релиз с исправлениями безопасности 12 ноября 2026 года, после чего версия официально становится unsupported[1][2]. Дальше любая новая уязвимость останется без патча. Правильная последовательность действий: провести инвентаризацию всех инстансов PG14, проверить совместимость расширений, выбрать между pg_upgrade (быстро, но с простоем) и логической репликацией (почти без простоя, но сложнее в настройке), заранее оценить время простоя на копии продакшена, убедиться, что бэкап реально восстанавливается, а не просто «создаётся», проверить после миграции кодировки, локали и критичные запросы, и держать наготове план отката. Ниже — конкретный маршрут для каждого из этих шагов.

Почему это не «когда-нибудь потом»

Окончание поддержки версии СУБД — это не абстрактная формальность. PostgreSQL публикует минорные релизы с исправлениями багов и уязвимостей не реже одного раза в три месяца, а критичные проблемы безопасности могут закрываться внеплановыми выпусками[1]. После даты EOL этот процесс для конкретной ветки просто останавливается: PostgreSQL 14.24, вышедший 13 августа 2026 года, стал одним из последних плановых релизов перед финальным минорным обновлением в ноябре[2]. Если в базе, работающей на PG14, найдут уязвимость после этой даты — патча не будет никогда.

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

Второй практический момент — время. Мажорный апгрейд PostgreSQL это не обновление пакета одной командой. Это отдельный проект с тестированием, окном простоя, подготовкой отката и проверкой после переключения. Начинать его планирование в последние недели перед EOL — типичная ошибка, которая приводит либо к спешке и авариям, либо к работе на неподдерживаемой версии месяцами.

Что скрывается за «концом поддержки»

PostgreSQL Global Development Group выпускает новую мажорную версию примерно раз в год и поддерживает каждую пять лет с момента первого релиза[1]. Мажорная версия — это первая часть номера (14, 15, 16...); минорная — вторая (14.23, 14.24). Минорные обновления не меняют формат данных и устанавливаются простой заменой бинарников и рестартом сервера. Мажорные — меняют внутренний формат системных таблиц, поэтому требуют либо выгрузки/загрузки данных, либо специального инструмента pg_upgrade[3].

Официальная таблица версий показывает конкретные даты: PostgreSQL 14 вышел 30 сентября 2021 года и завершает поддержку 12 ноября 2026-го; версия 13 уже unsupported с ноября 2025-го[1]. Проект прямо рекомендует всегда работать на последней минорной версии своей мажорной ветки, а «продолжать эксплуатацию старой минорной версии community считает более рискованным, чем обновиться»[1].

Шаг 1. Найти все экземпляры PostgreSQL 14

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

• Пройтись по всем known-серверам и облачным ресурсам (RDS/managed-инстансы, self-hosted VM, контейнеры) и выполнить SELECT version(); или проверить версию через pg_controldata.
• Проверить конфигурации CI/CD и Docker-образы — версия PostgreSQL часто «зашита» в docker-compose или Dockerfile и не совпадает с продакшеном.
• Отдельно поискать standby- и реплика-серверы: при апгрейде через pg_upgrade все стриминговые и log-shipping реплики должны оставаться запущенными до момента остановки мастера, чтобы успеть получить все изменения[3].
• Проверить внешние SaaS/PaaS-платформы, где заказчик мог сам развернуть управляемый PostgreSQL 14 (Heroku, различные DBaaS) — там часто ответственность за апгрейд формально лежит на провайдере, но сроки нужно уточнять отдельно.

Итог этого шага — реестр инстансов с версией, ролью (продакшен/реплика/staging), объёмом данных и списком расширений, который понадобится на следующем шаге.

Шаг 2. Проверить расширения и их совместимость

Это самый недооценённый источник сюрпризов при мажорном апгрейде. pg_upgrade переносит определения объектов, но не сами файлы расширений: shared-объекты (.so/.dll) новой версии должны быть установлены в новом кластере заранее, при этом схему CREATE EXTENSION заново выполнять не нужно — она переносится автоматически[3]. Если для расширения, которое использовалось в старом кластере, нет сборки под новую версию PostgreSQL, pg_upgrade либо сообщит об ошибке на этапе проверки, либо (что хуже) даст неполный результат.

Практические шаги:

1. Составить список установленных расширений: SELECT extname, extversion FROM pg_extension; на каждой базе.
2. Для каждого расширения проверить наличие сборки под целевую версию PostgreSQL (для проприетарных расширений — у вендора, для community — в репозитории PGDG или исходниках).
3. Помнить, что pg_upgrade не умеет мигрировать столбцы с типами regproc, regoper, regoperator, regconfig, regdictionary, regnamespace, regcollation — такие столбцы придётся обработать отдельно до апгрейда[3].
4. Проверить кастомные full-text search словари, тезаурусы, синонимы — их файлы нужно вручную скопировать в новый кластер[3].
5. Прогнать pg_upgrade --check — режим, который выполняет все проверки совместимости без изменения данных и заранее показывает, что придётся исправить вручную[3].

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

Шаг 3. pg_upgrade, логическая репликация или дамп/restore — что выбрать

pg_upgrade: быстро, но с простоем

pg_upgrade создаёт новый кластер и переиспользует старые файлы данных вместо их выгрузки и загрузки, что делает апгрейд значительно быстрее полного dump/restore[3]. Есть три режима копирования данных:

• copy (по умолчанию) — файлы физически копируются, самый безопасный вариант, но самый медленный на больших объёмах;
• link — вместо копирования создаются жёсткие ссылки, апгрейд занимает минуты вне зависимости от размера базы, но после старта нового кластера старый становится непригодным для запуска[3];
• clone/copy-file-range — используют возможности файловой системы (reflink на Btrfs/XFS/APFS) для почти мгновенного копирования при сохранении старого кластера нетронутым[3].

Ключевой практический момент: pg_upgrade требует полной остановки обеих СУБД на время апгрейда — это простой в прямом смысле слова, длительность которого зависит от количества объектов в схеме (не от объёма данных), плюс время на восстановление статистики после запуска.

Практический вывод: pg_upgrade — правильный выбор по умолчанию, когда бизнес может выдержать окно простоя от нескольких минут (режим link/clone) до пары часов (режим copy на больших объёмах), схема не перегружена кастомными типами и расширениями без сборки под новую версию, а переключение на логическую репликацию неоправданно усложнило бы проект. Для большинства внутренних систем и SaaS без жёсткого SLA на секунды простоя это самый предсказуемый и наименее рискованный путь.

Логическая репликация: путь к минимальному простою

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

Здесь важно на что не рассчитывать. Начиная с PostgreSQL 17, pg_upgrade умеет автоматически переносить логические слоты репликации между кластерами — но эта возможность работает, только если исходный кластер уже имеет версию 17 или новее[4]. Для перехода именно с PostgreSQL 14 это не подходит: нужно настраивать publication/subscription «классическим» способом, вручную создавая объекты на обеих сторонах[4].

При этом логическая репликация в PostgreSQL имеет содержательные ограничения, которые нужно учитывать при планировании:

• DDL-команды не реплицируются — структуру таблиц на новом кластере нужно создавать заранее вручную (например, через pg_dump --schema-only), а изменения схемы во время параллельной работы обеих баз синхронизировать вручную[5].
• Данные последовательностей (sequence) не реплицируются — значения identity-столбцов передаются как часть строк таблицы, но сам объект SEQUENCE на подписчике останется со стартовым значением, и его нужно будет довести до актуального состояния перед переключением трафика[5].
• Большие объекты (Large Objects) логической репликацией не передаются[5].
• Материализованные представления не обновляются автоматически — нужен отдельный механизм рефреша на новой стороне.

Практический вывод: логическая репликация подходит, когда простой критичен, а схема базы относительно стабильна и не использует активно большие объекты. Если это не так, лучше закладывать time-boxed окно простоя под pg_upgrade и параллельно инвестировать в ускорение самого апгрейда (режим link/clone, распараллеливание через --jobs)[3].

Dump/restore: универсальный, но самый медленный вариант

Полный pg_dump/pg_restore остаётся резервным вариантом, когда pg_upgrade невозможен (например, из-за несовместимости бинарных форматов при смене архитектуры процессора или дистрибутива с другой версией glibc — об этом ниже) или когда одновременно с версией СУБД меняется её вендор (переход на форк, например Postgres Pro). Минус очевиден: время restore прямо пропорционально объёму данных, а не количеству объектов схемы, поэтому для баз в сотни гигабайт и выше это, как правило, самый долгий путь.

Шаг 4. Как оценить время простоя, а не гадать

Оценка простоя должна строиться на измерениях, а не на интуиции. Практический алгоритм:

1. Сделать копию продакшен-базы на отдельном стенде того же класса оборудования (диск, процессор, объём памяти) — тестировать на маломощной виртуалке бессмысленно, цифры не перенесутся.
2. Прогнать полный цикл выбранного метода апгрейда (pg_upgrade --check, затем реальный pg_upgrade в нужном режиме, либо полный цикл настройки логической репликации) и замерить время каждого этапа отдельно: остановка старого кластера, сам апгрейд, запуск нового, обязательный ANALYZE/vacuumdb после апгрейда.
3. Повторить прогон 2-3 раза — первый прогон часто медленнее из-за холодных кэшей файловой системы.
4. Отдельно замерить, сколько времени требуется на смоук-тесты после запуска нового кластера — само по себе окно простоя часто недооценивают именно на этом шаге, потому что запуск сервера ещё не значит, что приложение готово принимать полную нагрузку.
5. Учесть, что до PostgreSQL 18 статистика планировщика не переносится при pg_upgrade вообще — это официально задокументированное поведение, и без ручного запуска ANALYZE (или сгенерированного pg_upgrade скрипта analyze_new_cluster.sh) первые запросы после апгрейда пойдут по плохим планам, поскольку планировщик считает статистику пустой[3][11]. На больших таблицах полный ANALYZE может занимать часы, и его нужно закладывать в окно простоя или выполнять поэтапно через vacuumdb --all --analyze-in-stages --missing-stats-only, что быстрее восстанавливает минимальную статистику для всех отношений[3].

Для бизнеса результат этого шага — не единая цифра «X минут простоя», а диапазон с указанием, какая часть окна приходится непосредственно на переключение, а какая — на стабилизацию производительности после старта.

Шаг 5. Резервная копия: создание — не то же самое, что защита

Одна из самых частых причин, по которой мажорный апгрейд превращается в инцидент — уверенность, что «бэкап есть», при том что его никто не восстанавливал. Практика показывает: бэкап может успешно создаваться неделями подряд, при этом быть непригодным для восстановления из-за проблем с правами доступа, битых файлов или неполного набора объектов[13].

Правильная проверка резервной копии — это не проверка кода возврата job'а, а фактическое восстановление:

• Регулярные (например, еженедельные) тестовые восстановления полной копии на отдельный стенд с последующей проверкой количества таблиц, строк в ключевых таблицах и работоспособности критичных запросов[14].
• Для физических бэкапов (pg_basebackup) — проверка контрольных сумм через pg_verifybackup, которая явно указывает на конкретный повреждённый файл, если целостность нарушена[14].
• Если в инфраструктуре используется pg_probackup (распространённый в российских инсталляциях инструмент для инкрементального бэкапа PostgreSQL/Postgres Pro), команда validate проверяет, можно ли восстановиться из конкретной копии до нужной точки во времени, включая проверку целостности цепочки инкрементальных бэкапов до полного[15].
• Полный (end-to-end) тест восстановления с реальным поднятием сервера и прогоном smoke-тестов должен проводиться не реже раза в месяц — именно такая частота считается минимально достаточной для production-систем[14].

Отдельная рекомендация именно перед мажорным апгрейдом: сделать полный бэкап непосредственно перед началом работ и обязательно восстановить его на отдельном стенде до того, как трогать продакшен — это последняя проверка перед точкой невозврата.

Шаг 6. Что проверить после миграции

Кодировки и локали

Если апгрейд происходит одновременно со сменой операционной системы или контейнерного образа, есть риск получить рассинхронизацию версии библиотеки glibc, которая отвечает за сортировку строк (collation). Классический пример — переход glibc с версии 2.17 на 2.28 (например, при смене базового образа RHEL7 → RHEL8/аналоги на Ubuntu), где обновление данных локализации привело к массовой незаметной порче индексов по всему миру: строки начали сортироваться иначе, уникальные ограничения — пропускать дубликаты, а PostgreSQL и операционная система при этом не сообщали об ошибке[6].

Начиная с PostgreSQL 13 сервер сам логирует предупреждение о несовпадении версии коллации при подключении к базе:

WARNING: collation "xx-x-icu" has version mismatch
DETAIL: The collation in the database was created using version 1.2.3.4,
but the operating system provides version 2.3.4.5.

Появление такого сообщения — сигнал, что REINDEX обязателен[6]. Безопасный подход для кластеров на glibc-коллациях — перестраивать все текстовые индексы после любого мажорного обновления ОС, без исключений, используя REINDEX INDEX CONCURRENTLY для минимизации простоя[6]. Если PostgreSQL уже какое-то время стабильно работает на актуальной версии glibc без проблем, при последующем повышении версии ОС (например, с glibc 2.28 на 2.34) риск обычно ниже, но диагностический запрос по pg_collation всё равно стоит прогнать перед апгрейдом[7].

Практическая проверка перед миграцией:

SELECT collname, collversion,
       pg_collation_actual_version(oid) AS actual_version
FROM pg_collation
WHERE collprovider IN ('c', 'i');

Если collversion не совпадает с actual_version — есть кандидаты на REINDEX уже сейчас, до апгрейда СУБД.

Критичные запросы

Перед миграцией стоит зафиксировать план выполнения ключевых для бизнеса запросов (логин, оформление заказа, дашборды, биллинг) через EXPLAIN (ANALYZE, BUFFERS) на старой версии, а после миграции сравнить их с планами на новой. Это позволяет отличить «нормальную» временную деградацию из-за отсутствующей статистики (лечится ANALYZE) от реальной регрессии планировщика, требующей отдельного разбирательства.

Кодировка клиента и сравнение результатов

Стоит явно проверить, что кодировка клиента (client_encoding) и настройки локали (LC_COLLATE, LC_CTYPE) на новом кластере совпадают с ожидаемыми, особенно если инициализация нового кластера (initdb) выполнялась без явного указания флагов, совпадающих со старым кластером[3].

Шаг 7. План отката

Откат нужно готовить заранее, а не придумывать в момент аварии. Варианты зависят от выбранного режима апгрейда:

• Если использовался pg_upgrade --check — старый кластер не менялся вообще, откат тривиален: он просто перезапускается[3].
• Если использовался режим copy (по умолчанию) без --link/--swap — старый кластер не изменяется, и до удаления его директорий можно просто вернуться к нему[3].
• Если использовался режим link — после старта нового кластера старый становится небезопасным для запуска и потребует восстановления из бэкапа; если новый кластер ещё не стартовал, достаточно убрать суффикс .old у файла pg_control и перезапустить старый[3].
• Если использовался режим swap — после того как pg_upgrade сообщил, что старый кластер более не безопасен для запуска, откат возможен только из резервной копии[3].
• При логической репликации откат проще по своей природе: старый кластер продолжает принимать запись до фактического переключения трафика, поэтому пока переключение не выполнено, можно просто не выполнять его и разбираться с проблемой на новом кластере отдельно.

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

Российская специфика: Postgres Pro и реестр отечественного ПО

Для государственных организаций и компаний, обязанных использовать программное обеспечение из Единого реестра российских программ, обычный community-релиз PostgreSQL сам по себе в реестре не значится. Альтернативой выступает Postgres Pro — коммерческий форк PostgreSQL от компании Postgres Professional, включённый в реестр отечественного ПО ещё в марте 2016 года и сертифицированный ФСТЭК России по требованиям к средствам вычислительной техники и отсутствию недекларированных возможностей[8][9].

На практике это означает, что при планировании перехода с PostgreSQL 14 государственным организациям и регулируемым отраслям (банки и т.п.) стоит рассматривать не просто «апгрейд до PostgreSQL 17/18», а более широкий вопрос — переход на сертифицированный форк как целевую платформу, особенно если ранее использовавшиеся зарубежные решения (Oracle, MS SQL) также попадают под замещение[10]. Здесь стратегия миграции усложняется: помимо мажорного апгрейда версии, может потребоваться перенос данных между разными сборками PostgreSQL, что чаще делается через логическую репликацию или dump/restore, а не через pg_upgrade, если версии бинарно несовместимы.

Для компаний, которым реестр не требуется и которые продолжают использовать community-версию PostgreSQL, ключевая рекомендация не меняется: следить за собственным циклом поддержки версии независимо от политических и регуляторных изменений, поскольку дата EOL для PostgreSQL 14 фиксирована и не зависит от локальных обстоятельств[1][2].

Частые ошибки при мажорном апгрейде

• Считать, что «оптимизатор статистику перенёс». До PostgreSQL 18 это не так: без ручного ANALYZE планировщик стартует «вслепую» и может отдать предпочтение полному сканированию таблицы вместо индекса[11][12].
• Апгрейдить СУБД и ОС одновременно без проверки коллаций. Смена версии glibc параллельно с апгрейдом PostgreSQL — известный источник тихой порчи индексов[6][7].
• Полагаться на «зелёный» статус job'а резервного копирования. Только фактическое восстановление подтверждает, что бэкап рабочий[13][14].
• Настраивать логическую репликацию и забывать про DDL и sequences. Изменения схемы во время параллельной работы двух кластеров нужно применять на подписчике вручную, а значения последовательностей — досчитывать перед переключением трафика[5].
• Не тестировать процедуру на копии реального объёма данных. Время апгрейда и особенно время последующего ANALYZE сильно зависит от объёма и распределения данных — экстраполировать с тестовой базы в 1 ГБ на продакшен в 500 ГБ не получится.

Как может помочь «Пятый фактор»

Основная сложность мажорного апгрейда PostgreSQL обычно не в самой команде pg_upgrade, а в оценке рисков конкретной инсталляции: какие расширения совместимы, какое реальное время простоя выдержит бизнес, какая стратегия резервного копирования уже используется и насколько она надёжна, и какой сценарий отката подходит именно этой архитектуре. Команда «Пятого фактора» может изучить текущую конфигурацию базы данных, оценить возможные варианты миграции — от pg_upgrade на месте до логической репликации или перехода на сертифицированный форк вроде Postgres Pro — и помочь с разработкой плана обновления, тестированием на копии продакшена и технической консультацией по конкретным узким местам инфраструктуры.

Если для задачи достаточно самостоятельного прогона pg_upgrade --check и пары тестовых восстановлений бэкапа — честно говоря, отдельная разработка тут не нужна: описанный в статье чек-лист можно выполнить силами внутренней команды. Разработка и консультации имеют смысл там, где на кону нестандартная архитектура (много расширений, кастомные типы данных, требования к нулевому простою, регуляторные ограничения) или где команде не хватает ресурсов на полноценное тестирование сценария заранее.

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

Вывод

12 ноября 2026 года PostgreSQL 14 официально выходит из под поддержки[1][2]. У компаний, работающих на этой версии, есть достаточно времени, чтобы провести миграцию спокойно — но только если начать с инвентаризации сейчас, а не в последний месяц. Правильная последовательность действий проста по формулировке и трудоёмка по исполнению: найти все инстансы, проверить расширения, выбрать стратегию апгрейда исходя из допустимого простоя, измерить реальное время на копии продакшена, убедиться, что резервная копия действительно восстанавливается, проверить коллации и статистику после переключения, и держать наготове чёткий план отката с заранее определёнными критериями «идём назад». Мажорный апгрейд PostgreSQL — управляемый проект, если разложить его на эти шаги заранее, а не разбираться с ними в разгар инцидента.

Источники

[1] postgresql.org — Versioning Policy — https://www.postgresql.org/support/versioning/

[2] postgresql.org — Главная страница проекта (уведомление о EOL PostgreSQL 14) — https://www.postgresql.org/

[3] postgresql.org — pgupgrade — https://www.postgresql.org/docs/current/pgupgrade.html

[4] postgresql.org — 29.13. Upgrade (обновление логической репликации) — https://www.postgresql.org/docs/current/logical-replication-upgrade.html

[5] postgresql.org — 29.8. Restrictions (ограничения логической репликации) — https://www.postgresql.org/docs/current/logical-replication-restrictions.html

[6] pgedge.com — What is a Collation, and Why is My Data Corrupt? — https://www.pgedge.com/blog/what-is-a-collation-and-why-is-my-data-corrupt

[7] docs.gitlab.com — Upgrading operating systems for PostgreSQL — https://docs.gitlab.com/administration/postgresql/upgrading_os/

[8] catalog.arppsoft.ru — СУБД Postgres Pro: Каталог совместимости российского ПО — https://catalog.arppsoft.ru/product/6030790

[9] handy-soft.ru — Переход на PostgreSQL и Postgres Pro — https://handy-soft.ru/services/perehod-na-postgresql-i-postgres-pro/

[10] itentika.ru — Процесс импортозамещения СУБД на Postgres Pro — https://itentika.ru/news/migracia_subd_na_postgres

[11] cybertec-postgresql.com — Optimizer statistics preserved during upgrade in PostgreSQL v18 — https://www.cybertec-postgresql.com/en/preserve-optimizer-statistics-during-major-upgrades-with-postgresql-v18/

[12] postgres.ai — PG18 preserves planner statistics on upgrade — even from PG14 — https://postgres.ai/blog/20260324-pg18-stats-upgrade-across-versions

[13] dev.to — PostgreSQL backup verification — How to test and validate your PostgreSQL backups — https://dev.to/piteradyson/postgresql-backup-verification-how-to-test-and-validate-your-postgresql-backups-2al8

[14] oneuptime.com — How to Test PostgreSQL Backup Restoration — https://oneuptime.com/blog/post/2026-01-21-postgresql-backup-testing/view

[15] postgrespro.com — pgprobackup (документация) — https://postgrespro.com/docs/postgrespro/11/app-pgprobackup