Почему многие пользуются древними версиями Postgres?

Postgres 17.0 уже вышла, и она замечательная, но реальность такова: большинство пользователей Postgres не выполняют апгрейд сразу же. Многие, вероятно, сейчас даже не на 16.4, и даже не на 16, они пользуются Postgres 15 или ещё более старой версией. Ситуация с Postgres не такая же, как с новыми Call of Duty, когда каждый хочет скачать обновление сразу же после его выхода.

Почему же люди так неохотно идут на апгрейд?

На то есть множество причин, но всё сводится к двум основным: качество работы Postgres и неудобство апгрейдов.

▍ Фундаментальное величие Postgres

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

И Postgres был отличным инструментом за много версий до 17. Старые версии Postgres более чем справляются с тем, что нужно большинству разработчиков. Базовая функциональность Postgres присутствует в ней уже много лет. Фундаментальная мощь Postgres заключается в том, что она позволяет разработчикам создавать надёжные масштабируемые приложения, не задумываясь о версии базы данных.

Но это не значит, что Postgres не совершенствуется

Например, допустим, вы сейчас работаете с версией 12. С её выпуска производительность Postgres существенно выросла:

• В Postgres 13 повышена скорость обработки запросов, использующих агрегатные функции или разделённые на секции таблицы (partitioned table).
• В Postgres 14 появилось множество улучшений производительности, связанных с параллельными запросами, активно использующими конкурентность нагрузками, partitioned table, логической репликацией и высвобождением пространства (vacuuming).
• В Postgres 15 внедрены улучшения производительности, в частности, связанные с сортировкой в памяти и на диске.
• В Postgres 16 повышена производительность vacuum freezing и логической репликации из реплик.

Такие внутренние улучшения крайне важны для повышения качества приложений. Между версиями Postgres 8 и 16 время задержки уменьшилось наполовину (за секунду):

И мы ещё не говорили об усилении безопасности, устранении багов и, разумеется, о новых возможностях. В новых версиях появилась поддержка SQL-команды MERGE, конструкторов SQL/JSON, тождественных отображений, распараллеленного vacuuming индексов…

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

▍ Затраты на изменения

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

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

▍ Истории об апгрейде из реальной жизни

Чтобы осознать картину, давайте рассмотрим две опубликованные истории компаний, выполнивших апгрейды Postgres в продакшене с перепрыгиванием нескольких основных версий: Knock (она обновлялась с Postgres 11 до 15) и Retool (с Postgres 9 на 13). Это серьёзный переход, к которому нужно готовиться стратегически.

Этим компаниям пришлось сделать следующее:

1. Оценка и планирование. Они оценили размеры и рабочие нагрузки своих баз данных (у Retool была база данных на 4 ТБ; Knock владела несколькими базами данных). Компании поставили следующие цели: минимизация даунтайма и апгрейд до завершения end-of-life. Они выбрали целевые версии Postgres и составили подробные графики реализации проекта и оценку рисков.
2. Подготовка репликации Были запущены новые инстансы баз данных с целевыми версиями Postgres и выполнена логическая репликация со старых на новые базы данных. Для реализации первоначального дампа и восстановления Retool воспользовалась Warp, а Knock создал собственные публикации и подписки для инкрементальной миграции.
3. Инкрементальная миграция данных. Таблицы были разбиты на категории по размеру и частоте обновлений. Маленькие таблицы добавили в репликацию и синхронизировались быстро. Для крупных таблиц, рассчитанных только на добавление данных, компании использовали отдельные публикации с copy_data = false с последующим backfilling. Для крупных часто обновляющихся таблиц были разработаны индивидуальные стратегии миграции.
4. Тестирование и верификация. На новых версиях баз данных было проведено тщательное тестирование. Компании сравнивали количество строк и сэмплировали данные между старыми и новыми базами данных, проводили нагрузочные тесты для проверки производительности и выполнили множественные тестовые прогоны в staging-окружениях.
5. Изменения в приложениях. После тестирования компании внесли изменения в свои приложения, обеспечив поддержку подключений и к старым, и к новым базам данных. Были реализованы механизмы для переключения трафика со старых на новые базы данных, например, флаги фич.
6. Стратегия окончательного переключения. Этап окончательного перехода был запланирован на периоды с низким трафиком. Retool использовала окно технического обслуживания длительностью примерно один час, а Knock обеспечила почти нулевой даунтайм с небольшой паузой в новых запросах.
7. Задачи после миграции. Далее они верифицировали целостность данных и функциональность приложений, оптимизировали новые базы данных (например, выполнили переиндексацию и vacuuming), проводили в последующие дни мониторинг, удалили старые системы репликации и вывели из эксплуатации старые базы данных.

Да, это большой объём работы, и его никак не избежать. Апгрейд базы данных Postgres в продакшене вперёд на несколько версий требует существенных вложений времени и ресурсов. Многие организации может пугать такой объём затрат, поэтому они часто откладывают апгрейды до тех пор, пока те не станут абсолютно необходимы.

▍ Аргументы в пользу апгрейдов

Несмотря на всё это, мы рекомендуем вам апгрейдиться!

Даже если вас не убедили потрясающие новые возможности Postgres 17, то есть и другие причины:

• Вам всё равно придётся это сделать рано или поздно. Версии Postgres имеют жизненный цикл, и поддержка каждой версии когда-то закончится (спустя пять лет после релиза).
• Перепрыгивать несколько версий за раз сложнее. Чем дольше вы откладываете апгрейд, тем больше версий вам придётся в итоге перепрыгнуть. В случае апгрейда лучше перепрыгивать как можно больше версий, но если вы пропустите пять или больше версий, то возникнет множество проблем с совместимостью и изменений, ломающих обратную совместимость.
• Ваше приложение может потерять актуальность. Новые версии Postgres содержат оптимизации производительности и новые возможности, которые могут улучшить ваши приложения. Оставаясь на старой версии, вы не сможете воспользоваться теми улучшениями, которые могут повысить скорость и эффективность вашей системы.
• Совместимость. Новые фреймворки, библиотеки и инструменты могут выпускаться без совместимости со старыми версиями Postgres. Обновлённые API или расширения могут не иметь обратной совместимости, мешая интеграции инструментов или требуя сложных обходных решений.

▍ Проверьте, что вы теряете: pgversions.com

Частично отсутствие мотивации к апгрейду вызвано необходимостью ручного сравнения release notes между версиями и выявлением недостающих вам улучшений. Чтобы упростить этот процесс, мы создали инструмент https://pgversions.com/. Он позволяет быстро выявлять улучшения, которые вам недоступны из-за использования старой версии Postgres. Например, если у вас установлена Postgres 16.1, то pgversions.com сообщит, что вам недоступны:

• 4 улучшения безопасности.
• 177 баг-фиксов.
• 24 улучшения производительности.
• 10 новых функций.

Если pgversions наконец-то придаст вам мотивации к апгрейду, то можете изучить раздел отчёта How to upgrade, в котором приведены ссылки на документацию различных поставщиков.