PostgreSQL 14 перестанут поддерживать 12 ноября 2026: после последнего релиза патчей безопасности не будет
До конца поддержки меньше месяца, а переход на новую мажорную версию базы нельзя сделать в пятницу вечером одной командой.
Сообщество PostgreSQL поддерживает каждую мажорную версию (первое число в номере, например 14 или 15) пять лет после первого выпуска. Для четырнадцатой версии этот срок заканчивается: по таблице версий на postgresql.org, последний релиз выйдет 12 ноября 2026 года. Первый вышел 30 сентября 2021-го, текущий минорный выпуск (мелкое обновление с исправлениями) — 14.24.
После финального релиза версию объявят неподдерживаемой. Исправлений ошибок и закрытия новых уязвимостей для неё больше не будет. База продолжит работать, но найденная завтра дыра в 14-й версии останется открытой. Для интернет-магазина, CRM или внутренней системы с персональными данными это уже вопрос рисков, а не вкуса админа.
Последний релиз выйдет в день конца поддержки
График минорных релизов публикуется заранее: 12 ноября 2026, затем 11 февраля, 13 мая и 12 августа 2027. Ноябрьская дата совпадает с датой окончания поддержки в таблице версий. Сама страница графика прямо не называет этот выпуск финальным для 14-й версии, это следует из таблицы. После него версия считается неподдерживаемой (end-of-life), и дальше остаётся только переезд на другую мажорную.
Остальные версии в таблице живут дольше:
- 15 — до 11 ноября 2027, текущий минор 15.19
- 16 — до 9 ноября 2028, текущий минор 16.15
- 17 — до 8 ноября 2029, текущий минор 17.11
- 18 — до 14 ноября 2030, текущий минор 18.6
Переходить на 15-ю версию смысла мало: поддержка закончится через год, и вся работа повторится. Логичнее целиться в более свежую.
Мажорное обновление не делается заменой пакета
Минорные обновления (14.23 → 14.24) простые: остановить сервер, поставить новые бинарники, запустить. С мажорными иначе. Проект пишет прямо: формат каталога данных между мажорными версиями не сохраняется, поэтому нужен либо дамп и загрузка базы (dump/reload), либо утилита pg_upgrade. Промежуточные версии проходить не обязательно, но проект советует прочитать заметки к выпускам всех версий между старой и новой.
Дамп и загрузка выгружают и загружают данные целиком, так что простой, скорее всего, растёт вместе с размером базы. pg_upgrade по документации создаёт новые системные каталоги и использует прежние файлы данных. Режим копирования (по умолчанию) копирует их все. Режимы --link (жёсткие ссылки) и --clone заметно быстрее, но требуют, чтобы старый и новый каталоги лежали в одной файловой системе.
У --link есть цена: как только новый кластер запущен, старый пользоваться уже нельзя, откат — только из резервной копии. Поэтому в документации и стоит оговорка, что режим копирования оставляет старую базу нетронутой.
Репетиция на копии показывает грабли заранее
У pg_upgrade есть ключ --check: он проверяет совместимость и ничего не меняет. Его можно запускать, пока старый сервер работает, но тогда у старого и нового кластеров должны быть разные порты. Если добавить к нему и режим (например, --check --link), проверки будут точнее. Ещё из ограничений: таблицы со столбцами некоторых служебных типов (regproc, regoper и родственные) таким способом не обновить, а расширения нужно заранее установить под новую версию.
Есть и хвост после обновления: статистику планировщика (по ней база решает, как быстрее выполнить запрос) нужно пересобрать через vacuumdb --analyze-in-stages. Документация актуальной версии пишет, что свежий pg_upgrade переносит большую часть статистики сам. С какой версии это работает, проверять в документации целевой версии. Пока статистики нет, планы запросов, скорее всего, будут неудачными.
Что проверить у себя
- Выяснить, какие версии PostgreSQL стоят на всех серверах, включая забытые тестовые стенды и контейнеры с образами PostgreSQL 14.
- Решить, на какую версию переходить: 15-я закончится в ноябре 2027-го, у 17-й и 18-й запас до 2029 и 2030 годов.
- Прогнать pg_upgrade --check на копии боевой базы и записать, что он нашёл: несовместимые типы, расширения без сборки под новую версию.
- Замерить время обновления на копии с боевым объёмом данных и сравнить с допустимым простоем.
- Проверить, что резервная копия восстанавливается: особенно если планируется режим --link: после запуска нового кластера откат возможен только из неё.
- Если обновить к 12 ноября не успевают, записать это как принятый риск с датой и ответственным, а базу закрыть сетевыми правилами от всего лишнего.
Разборы аварий и практику для админов публикуем в Telegram-канале «Полный Ops».