Антон Дегтярёвкейс: миграция битрикс24 с mysql на postgresql
Первый вопрос, который я задаю клиенту, просящему перевести коробочный Битрикс24 на PostgreSQL: он в курсе, что для этого нужна отдельная лицензия "Энтерпрайз для Postgres" за 2 500 000 рублей, а обычная редакция Энтерпрайз с Postgres просто не запустится? Разбираю на реальном проекте, во что обходится этот переход и когда он вообще имеет смысл.
почему клиент вообще попросил postgresql
Запрос пришёл не от IT-отдела, а от руководителя: в компании приняли внутренний стандарт — вся инфраструктура на импортонезависимых решениях, включая СУБД. Коробочный Битрикс24 у клиента работал на MySQL пять лет без проблем, но формальное требование по импортозамещению обязывало пересмотреть базу данных вместе со всем остальным стеком.
Это типичная причина запроса на PostgreSQL — не техническая проблема с MySQL, а внешнее требование: регуляторика, корпоративный стандарт СУБД или контракт с госзаказчиком, где прописана импортонезависимая инфраструктура. Технических жалоб на производительность MySQL у клиента не было вообще, и это первое, что стоит прояснить до начала проекта — миграция ради миграции без реальной технической причины почти всегда стоит дороже, чем кажется на старте.
первое, что считаем — лицензия
Обычная лицензия "1С-Битрикс: Управление сайтом" редакции Энтерпрайз с PostgreSQL не работает — нужна отдельная редакция "Энтерпрайз для Postgres". Функционально она совпадает с обычным Энтерпрайзом, отличается только сборкой под другую СУБД и ценой: 2 500 000 рублей за лицензию с первым годом обновлений включённым.
Если у клиента уже была лицензия Энтерпрайз на MySQL, старая лицензия для новой редакции не переиспользуется — это отдельная покупка, а не апгрейд по доплате разницы. Для компаний, которые выбирали редакцию сайта без расчёта на переход на Postgres, это обычно первая цифра, которая охлаждает энтузиазм — я подробно разбирал, как вообще выбирать редакцию 1С-Битрикс, в статье про выбор редакции.
что отключается — 18 модулей, а не мелочи
Здесь начинается разговор, который обычно меняет решение клиента: при переходе на PostgreSQL в Битрикс24 отключается до 18 модулей системы. Среди них — BI-коннектор и конструктор отчётов, инструменты веб-аналитики и A/B-тестирования, веб-формы, баннеры и рекламные модули. Это не второстепенный функционал — в случае моего клиента BI-конструктором ежедневно пользовался весь отдел продаж для собственных отчётов по воронке.
Узнав об этом, руководитель отдела продаж заблокировал проект на уровне согласования: терять готовый инструмент отчётности ради формального соответствия стандарту СУБД оказалось неприемлемо. Список отключаемых модулей — это первое, что я прошу клиента свести с фактическим использованием функционала в компании, до того как считать бюджет миграции: если хотя бы один из 18 модулей — рабочий инструмент для ключевого отдела, разговор о переходе стоит останавливать на этом этапе.
как проходит сама миграция технически
Официальный процесс описан в учебном курсе на портале разработчиков dev.1c-bitrix.ru — там же лежат инструкции по установке и настройке окружения PostgreSQL перед переносом данных. На практике проект идёт в три захода: разворачивается тестовое окружение (обычно на BitrixVM), туда переносится копия рабочей базы конвертером, и на этой копии проверяется, что сайт и все критичные бизнес-процессы работают на новой СУБД без деградации.
Только после того как тестовый контур отработал без критичных ошибок хотя бы 1-2 недели под наблюдением, имеет смысл планировать перенос боевой базы. Сокращать этот этап тестирования — самая частая причина, по которой миграция на PostgreSQL оборачивается простоем сайта уже после переключения, а не до него.
где именно ломается кастомный код
MySQL и PostgreSQL по-разному обрабатывают часть SQL-синтаксиса — это касается функций работы с датами, группировок и особенно прямых SQL-запросов, которые часто пишут в кастомных модулях и доработках под конкретного клиента. Если в проекте есть история кастомных доработок за несколько лет, часть из них почти гарантированно писалась с прямыми запросами под MySQL и без расчёта на смену СУБД.
Отдельная зона риска — модули из маркетплейса Битрикс24: разработчики сторонних решений не обязаны тестировать совместимость с PostgreSQL, и заранее нет способа узнать, заработает ли конкретное приложение на новой базе, кроме как проверить его в тестовом контуре. У клиента из этого кейса на этапе тестирования выявились проблемы в двух из семи установленных сторонних модулей — оба использовали прямые запросы к базе в обход штатного API.
По одному из этих модулей разработчик прислал обновлённую версию с исправленными запросами в течение недели, по второму — техподдержка ответила, что поддержка PostgreSQL не планируется, и модуль пришлось бы заменять на аналог целиком. Это стандартная ситуация: часть разработчиков маркетплейса активно обновляет продукты под новые редакции платформы, часть — нет, и узнать заранее, в какую категорию попадёт конкретное приложение, можно только написав в поддержку разработчика напрямую, а не по описанию в каталоге.
аудит кастомного кода до, а не во время миграции
Отдельный этап, который часто недооценивают в смете, — полный аудит кастомного кода на предмет прямых SQL-запросов до начала переноса, а не по факту поломки после переключения. На практике это грep по всей кодовой базе на характерные конструкции прямых запросов и ручная проверка каждого найденного места на совместимость синтаксиса с PostgreSQL.
Чем старше проект и чем больше в нём точечных доработок под конкретные задачи бизнеса за годы работы, тем длиннее список мест, которые нужно проверить руками. Пропустить этот аудит и понадеяться, что тестовый контур сам покажет все проблемы, — рискованно: часть багов, связанных с различиями в обработке дат и группировок между СУБД, проявляется не сразу, а только на определённых наборах данных или в определённые дни месяца, и в тестовом окружении за одну-две недели наблюдения их можно просто не увидеть.
сроки и необратимость решения
Полный проект перехода — от тестового окружения до боевого переключения с учётом нормального тестирования — занимает 1-2 месяца, и это без учёта переписывания сложных кастомных интеграций, если они обнаруживаются в процессе. Пытаться сжать этот срок под давлением дедлайна — прямой путь к тому, что часть проблем всплывёт уже на продакшене.
Отдельно стоит держать в голове: обратный переход с PostgreSQL на MySQL не предусмотрен как штатная процедура — вернуться можно только ручным переносом данных, который по трудозатратам сопоставим с исходной миграцией. Решение о переходе стоит принимать с пониманием, что откатить его "на всякий случай" почти так же дорого, как сам переход.
во сколько реально обходится проект
Смета миграции почти никогда не ограничивается ценой лицензии в 2,5 миллиона рублей. На моих проектах тестовое окружение, аудит кастомного кода на предмет прямых SQL-запросов и переписывание проблемных мест обычно добавляют ещё 30-40% к бюджету перехода сверх стоимости самой лицензии — и это без учёта модулей маркетплейса, которые могут потребовать замены на аналоги, совместимые с PostgreSQL.
В случае с клиентом из этого кейса после подсчёта полной стоимости — лицензия, тестирование, доработка кастомного кода и замена двух несовместимых модулей — и после того как выяснилось, что отключится BI-конструктор для отдела продаж, компания приняла решение остаться на MySQL и закрыть формальное требование импортонезависимости на уровне остальной инфраструктуры, не трогая CRM.
когда переход всё-таки оправдан
PostgreSQL имеет смысл, если у компании реально высокая нагрузка с большим количеством параллельных операций записи, big data объёмы и сложные аналитические запросы, для которых PostgreSQL архитектурно эффективнее, или если импортонезависимость — не формальное пожелание, а жёсткое контрактное или регуляторное требование без права выбора. В этих случаях цена лицензии и потеря части модулей — оправданная плата за соответствие требованиям или за реальный прирост производительности на масштабе.
Для типового внедрения CRM в режиме задач, чатов, сделок и стандартной аналитики MySQL остаётся оптимальным выбором — и это стоит проговаривать с клиентом на берегу, до того как проект перехода на Postgres запущен. Разница между "коробкой" и "облаком" Битрикс24 в принципе меняет набор доступных решений по СУБД и инфраструктуре — я разбирал этот выбор подробнее в статье облако или коробка Битрикс24. Если компания вообще рассматривает переход с облачного тарифа на коробку ради такой гибкости, порядок действий и подводные камни этого шага я отдельно разбирал в статье про переход с облака на коробку.