Миграция Битрикс24 с MySQL на PostgreSQL

Оглавление

Переезд коробочного Битрикс24 Enterprise с MySQL на PostgreSQL — это стратегическое решение, которое принимают тогда, когда компания вырастает: растёт объём данных, увеличивается нагрузка, появляются требования к отказоустойчивости, безопасности и импортозамещению. Или, когда это решение продиктовано требованиями к ИТ-инфраструктуре компании: стандартами информационной безопасности, корпоративной архитектурой, политикой импортозамещения, требованиями регуляторов или единым стеком СУБД внутри холдинга.

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

В этой статье — не теория, а практический план миграции: кому она действительно нужна, какие ограничения у Битрикс24 на PostgreSQL, как подготовиться к переезду без потери данных, как правильно выполнить перенос и что проверить после переключения. Материал основан на реальном опыте внедрения специалистами Цифрового Элемента и эксплуатации коробочной версии Битрикс24 Enterprise.

Почему и кому нужно переходит с MySQL на PostgreSQL в Битрикс24

В коробочной версии Битрикс24 исторически чаще используется MySQL, ведь портал создавался в 2010-х, — это проверенное, массовое и предсказуемое решение для чатов, задач, CRM, активной работы сотрудников в интерфейсе. В типовых сценариях MySQL работает стабильно и быстро, особенно при правильной настройке.

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

1. Корпоративные стандарты и единый стек технологий

Во многих холдингах и крупных организациях уже принят стандарт на использование PostgreSQL как основной СУБД. Это упрощает:

• сопровождение и DevOps-процессы,
• унификацию мониторинга,
• резервное копирование,
• кластеризацию и отказоустойчивость,
• обучение и поддержку администраторов.

Если вся ИТ-архитектура построена на PostgreSQL, логично, чтобы и Битрикс24 работал в том же стеке.

2. Требования информационной безопасности и регуляторов

Для ряда компаний критично соответствие требованиям ФСТЭК, импортозамещения или внутренним стандартам ИБ. PostgreSQL часто входит в утверждённый перечень допустимого ПО, а MySQL — нет (или требует дополнительных согласований).

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

3. Масштабирование и высокая нагрузка

Хотя Битрикс24 — это OLTP-система, и MySQL в большинстве случаев справляется отлично, при сложной архитектуре (кластер, репликация, распределённая инфраструктура) PostgreSQL может быть более удобным с точки зрения:

• гибкости настройки,
• работы со сложными запросами,
• продвинутых механизмов блокировок,
• расширяемости.

Особенно это актуально для порталов с:

• большим объёмом CRM-данных,
• активной интеграцией с внешними системами,
• множеством кастомных модулей.

4. Стратегия развития инфраструктуры

Иногда переход на PostgreSQL — часть более широкой трансформации:

• перенос в частное облако,
• переход на новую серверную архитектуру,
• консолидация баз данных,
• внедрение отказоустойчивого кластера.

В таких проектах Битрикс24 становится элементом общей архитектурной схемы, и выбор СУБД определяется стратегией компании, а не только техническими параметрами конкретного портала.

Важно понимать, что PostgreSQL — это не ускоритель Битрикс24

Один из распространённых мифов — «перейдём на PostgreSQL, и всё станет быстрее».

На практике всё зависит от нагрузки, структуры данных и качества настройки. В ряде сценариев MySQL показывает даже более высокую производительность в типичных транзакционных операциях Битрикс24.

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

Ограничения и особенности Битрикс24 при работе с PostgreSQL

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

1. Лицензирование

• Требуется специальная редакция «Программа для ЭВМ "1С-Битрикс: Управление сайтом". Лицензия Энтерпрайз для Постгрес», обычная лицензия «Энтерпрайз» с PostgreSQL не работает.
• Для перехода на PostgreSQL необходимо приобрести отдельную лицензию на переход «Программа для ЭВМ "1С-Битрикс: Управление сайтом". Лицензия Энтерпрайз для Постгрес (переход с Энтерпрайз)».
• Для тестирования миграции вендор предоставляет пробный ключ на шесть месяцев.
• PostgreSQL распространяется под собственной свободной лицензией (аналог BSD или MIT), есть документация на русском, профессиональная поддержка платная. В России, компанией Postgres Professional разрабатывается дистрибутив Postgres Pro, которая сертифицирована ФСТЭК и рядом крупных российских организаций с целью импортозамещения.

2. Ограничения по модулям

При работе на PostgreSQL часть модулей может быть недоступна или работать с ограничениями (официальный список поддержки модулей 1С-Битрикс24 в PostgreSQL). Среди них, такие модули как:

• BI-коннектор и конструктор отчетов,
• A/B-тестирование,
• веб-аналитика,
• часть веб-форм и механизмов лидогенерации,
• инструменты расчета конверсии,
• рекламные и баннерные модули,
• некоторые отчётные механизмы, использующие специфичные MySQL-функции.

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

3. Отличия в SQL и возможные ошибки в кастомном коде

PostgreSQL строже относится к синтаксису и типам данных. Что может работать в MySQL, в PostgreSQL может привести к ошибке.

Типичные проблемы:

• сравнение integer с пустой строкой или строкой типа «0»,
• некорректные операции GROUP BY / HAVING,
• неявные преобразования типов,
• использование специфичных функций MySQL,
• кавычки и регистр идентификаторов,
• LIKE/ILIKE и чувствительность к регистру,
• работа с датами и временными зонами,
• NULL-логика строже и очевиднее,
• прямые SQL-запросы в кастомных модулях.

Если в проекте есть доработки, собственные модули или сложные отчёты — их необходимо тестировать отдельно на тестовом стенде.

4. Технические различия СУБД

Нужно учитывать особенности архитектуры PostgreSQL:

• вместо AUTO_INCREMENT используются SEQUENCE,
• иная логика блокировок,
• отличия в работе индексов,
• статистика планировщика и ANALYZE,
• более строгая транзакционная модель,
• соединения и пуллинг,
• WAL и резервное копирование.

Это не недостатки, а особенности платформы. Но без понимания этих различий возможны ошибки при эксплуатации и настройке.

5. Обратный путь

Если в процессе миграции что-то пошло не так, то вернуться обратно на MySQL автоматически уже не получится. Только ручной перенос данных или восстановление из бэкапа.

Это означает, что решение о переходе должно быть взвешенным.

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

Поэтому до начала работ необходимо:

• проверить лицензию,
• проанализировать используемые модули,
• провести аудит кастомного кода,
• развернуть тестовый контур.

И только после этого переходить к технической части миграции.

В следующем разделе разберём, кому переход действительно оправдан, а кому разумнее сохранить MySQL.

Когда переходить на PostgreSQL?

Переходите	Подумайте	Оставайтесь на MySQL
Более 500 активных пользователей	Нагрузка начала расти	Типовое использование CRM
База данных более 50 ГБ	Отчёты формируются медленно	Нагрузка умеренная
Есть требования ФСТЭК / импортозамещения	Есть ресурсы на тестирование	Активно используются веб-формы и BI
Используются тяжёлые аналитические запросы	Не все модули критичны	Много сторонних модулей
Планируется масштабирование и кластер	Есть окно для миграции без критичного простоя	Система стабильно работает на MySQL

Вывод:

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

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

Основная ошибка при переходе на PostgreSQL — начинать с технической части. Правильная миграция начинается не с команды в консоли, а с подготовки. Чем лучше выполнен этот этап, тем меньше рисков простоя, потери данных и неожиданных ошибок после переключения.

1. Провести технический аудит текущего портала

Перед миграцией необходимо зафиксировать текущее состояние системы:

• версия Битрикс24 и установленных модулей,
• версия MySQL,
• объём базы данных,
• наличие кастомных модулей и доработок,
• прямые SQL-запросы в коде,
• интеграции с внешними системами.

Особое внимание стоит уделить самописным решениям. Если в коде используются нестандартные SQL-запросы, их нужно проверить на совместимость с PostgreSQL заранее.

2. Проверить используемые модули

Нужно определить:

• используются ли BI, веб-аналитика, A/B-тесты,
• есть ли маркетинговые инструменты, завязанные на MySQL,
• какие модули критичны для бизнеса.

Если часть функционала на PostgreSQL работать не будет, это должно быть известно до начала миграции, а не после запуска системы.

3. Развернуть тестовый стенд (обязательно)

Миграцию нельзя проводить сразу на боевом портале. Правильная схема:

1. Сделать копию портала (файлы + база).
2. Развернуть тестовый сервер с PostgreSQL.
3. Выполнить пробную миграцию.
4. Замерить:
   • время переноса,
   • объём данных,
   • количество ошибок,
   • производительность.

Только после успешного теста можно планировать боевой перенос.

4. Подготовить стратегию резервного копирования и отката

Перед миграцией должны быть:

• полный бэкап базы данных,
• бэкап файлов портала,
• возможность быстро вернуть систему на MySQL.

Важно заранее определить критерий отката. Например: если после запуска фиксируются критические ошибки или время отклика превышает допустимые значения — выполняется возврат на прежнюю СУБД.

5. Спланировать окно миграции

Необходимо:

• определить время простоя,
• уведомить сотрудников,
• заморозить изменения на портале,
• назначить ответственных (администратор, backend-разработчик, DevOps, QA-инженер и т.д.).

Даже при хорошей подготовке перенос может занять несколько часов — особенно если база данных превышает десятки гигабайт.

Главное правило: Миграция Битрикс24 на PostgreSQL — это проект, а не техническая операция.

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

Пошаговая миграция Битрикс24 с MySQL на PostgreSQL

После подготовки начинается техническая часть. Ниже — практический регламент действий, который мы используем в проектах. Он применим к коробочной версии Битрикс24 Enterprise и предполагает, что тестовая миграция уже была успешно выполнена.

Шаг 1. Подготовка сервера PostgreSQL

Перед переносом данных необходимо развернуть и настроить PostgreSQL:

• установить поддерживаемую версию PostgreSQL,
• создать отдельную базу данных и пользователя,
• настроить кодировку UTF-8,
• проверить параметры:
• shared_buffers,
• work_mem,
• maintenance_work_mem,
• max_connections,
• убедиться, что включён autovacuum.

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

Шаг 2. Финальный бэкап MySQL

Перед началом боевой миграции:

• остановить активные изменения (заморозить портал),
• выполнить полный дамп базы MySQL,
• сделать резервную копию файлов портала,
• при возможности — создать снапшот виртуальной машины.

Это точка возврата. Без неё начинать перенос нельзя.

Шаг 3. Перенос структуры и данных

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

• встроенный мастер Битрикс24,
• консольные инструменты,
• специализированные утилиты миграции.

В Enterprise-проектах чаще используется CLI-подход — он даёт больше контроля и лучше подходит для больших баз.

Во время переноса важно:

• корректно преобразовать AUTO_INCREMENT в SEQUENCE,
• проверить типы данных (особенно boolean, datetime, text),
• проконтролировать кодировку,
• отслеживать ошибки конвертации.

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

Шаг 4. Переключение портала на PostgreSQL

После успешного переноса:

• изменить параметры подключения к БД в конфигурации Битрикс24,
• проверить доступ к базе,
• выполнить очистку кеша,
• перезапустить веб-сервер и PHP.

Первый запуск может занять больше времени из-за перестроения кешей и генерации планов запросов.

Шаг 5. Первичная техническая проверка

Сразу после запуска необходимо:

• проверить логи PHP и PostgreSQL,
• убедиться, что нет ошибок типов и синтаксиса,
• сравнить количество записей в ключевых таблицах,
• протестировать авторизацию, CRM, задачи, поиск.

Если обнаружены критические ошибки — решение об откате принимается немедленно.

Шаг 6. Постмиграционная оптимизация

После запуска обязательно:

• выполнить ANALYZE по базе,
• проверить синхронизацию SEQUENCE,
• убедиться в корректной работе autovacuum,
• протестировать тяжёлые отчёты и интеграции,
• включить мониторинг медленных запросов.

Миграция считается завершённой не в момент запуска портала, а после того, как система стабильно работает под реальной нагрузкой.

Важно понимать: Технически перенос базы — это лишь половина работы. Основная сложность — обеспечить:

• отсутствие потери данных,
• корректность бизнес-логики,
• приемлемую производительность,
• предсказуемость работы под нагрузкой.

Именно поэтому проекты миграции требуют участия не только администратора, но и backend-разработчика и DevOps-инженера.

Проверка после миграции: технический и бизнес чек-лист

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

Ниже — практический чек-лист, который мы используем в проектах миграции.

1. Проверка целостности данных

• ☐ Количество пользователей совпадает с MySQL
• ☐ Количество сделок, лидов, контактов совпадает
• ☐ Количество задач совпадает
• ☐ Нет ошибок уникальных ключей (duplicate key)
• ☐ Проверены и синхронизированы SEQUENCE (нет риска конфликта ID)
• ☐ Проверена кодировка (UTF-8, корректное отображение кириллицы)
• ☐ Нет ошибок типов данных в логах PostgreSQL

2. Проверка технической корректности

• ☐ В логах PostgreSQL нет ошибок operator does not exist
• ☐ В логах нет ошибок relation does not exist
• ☐ Нет ошибок приведения типов (invalid input syntax)
• ☐ Выполнен ANALYZE после переноса
• ☐ Autovacuum включён и работает
• ☐ Нет долгих транзакций
• ☐ Нет зависших блокировок
• ☐ Размер таблиц и индексов адекватен (нет аномального bloat)

3. Проверка производительности

• ☐ Карточка сделки открывается без задержек
• ☐ Поиск по CRM работает быстро
• ☐ Отчёты формируются в разумное время
• ☐ Массовый импорт выполняется без деградации
• ☐ Бизнес-процессы запускаются корректно
• ☐ Нет всплесков CPU / RAM
• ☐ Нет резкого роста WAL

Если есть задержки — проверить планы запросов (EXPLAIN ANALYZE) и статистику.

4. Проверка бизнес-функционала

• ☐ Авторизация пользователей работает
• ☐ Права доступа корректны
• ☐ Роботы и автоматизация запускаются
• ☐ Уведомления приходят
• ☐ Почтовые обработчики работают
• ☐ Интеграция с 1С корректна
• ☐ Интеграции через API не выдают ошибок
• ☐ Телефония работает

5. Проверка кастомного кода

• ☐ Самописные модули работают без SQL-ошибок
• ☐ Нет падений в отчётах
• ☐ Нет ошибок GROUP BY / HAVING
• ☐ Нет ошибок ON CONFLICT / уникальности
• ☐ Проверены все cron-скрипты и агенты

6. Мониторинг в первые 72 часа

• ☐ Включено логирование медленных запросов
• ☐ Контролируется размер базы
• ☐ Контролируется рост индексов
• ☐ Отслеживаются долгие транзакции
• ☐ Проверяется работа autovacuum
• ☐ Настроен мониторинг (Zabbix / Prometheus / и т.п.)

Миграция считается успешной, если:

• ☑ Данные полностью совпадают
• ☑ Критичные бизнес-процессы работают
• ☑ Производительность не ниже прежней
• ☑ Нет SQL-ошибок
• ☑ Система стабильно выдерживает рабочую нагрузку

Оптимизация PostgreSQL под Битрикс24 после миграции

Если просто перенести базу и ничего не настраивать — PostgreSQL будет работать. Но чтобы он работал стабильно под нагрузкой Битрикс24 Enterprise, его необходимо правильно сконфигурировать и обслуживать.

Ниже — практические рекомендации, которые применяются в реальных проектах.

Область	Что проверить / настроить	Рекомендации для Enterprise
Память	shared_buffers	20–25% от RAM
	effective_cache_size	50–70% от RAM
	work_mem	16–64 MB (подбирать под нагрузку)
	maintenance_work_mem	256 MB – 1 GB
Autovacuum	Включён ли autovacuum	Обязательно включён
	Частота очистки	Проверить, нет ли накопления dead tuples
	Долгие транзакции	Исключить транзакции, блокирующие VACUUM
Статистика	Выполнен ли ANALYZE	Выполнить после миграции и массовых импортов
	Актуальность статистики	Контролировать при изменении структуры данных
Индексы	Соответствие реальным фильтрам	Проверить slow query log
	Составные индексы	Добавлять под реальные JOIN и WHERE
	Раздувание индексов	Контролировать bloat
Соединения	max_connections	Не завышать без необходимости
	Пул соединений	Использовать PgBouncer при высокой нагрузке
	Потребление RAM	Контролировать backend-процессы
WAL и бэкапы	Архивирование WAL	Настроить при использовании репликации или PITR
	Стратегия бэкапов	Full + WAL
	Тест восстановления	Регулярно проверять
Мониторинг	Медленные запросы	Включить логирование
	Блокировки	Контролировать долгие блокировки
	Рост базы	Отслеживать динамику
	Нагрузка на диск	Особенно при активной CRM

PostgreSQL требует регулярного обслуживания. Без контроля VACUUM, статистики и индексов производительность может снижаться постепенно и незаметно.

Чем заменить отключаемый функционал

Часть модулей, которые становятся недоступными при работе Битрикс24 на PostgreSQL, в реальных Enterprise-проектах используются редко. В большинстве случаев их можно либо безболезненно отключить, либо заменить более современными инструментами.

Реклама и баннеры

Модуль «Реклама и баннеры» предназначен для управления показом рекламных блоков на сайте.

На практике в корпоративных порталах с лицензией Enterprise его используют крайне редко — такие порталы не монетизируются за счёт баннерной рекламы. Если Битрикс24 применяется как внутренняя корпоративная система или CRM, функциональность рекламного модуля обычно не является критичной.

A/B-тестирование

Встроенный инструмент A/B-тестирования в Битрикс24 — не единственный способ проводить эксперименты.

Для этой задачи чаще используют специализированные внешние сервисы:

• «A/B эксперименты» и Varioqub от Яндекса,
• UX Rocket,
• другие инструменты продуктовой аналитики.

Во многих компаниях A/B-тестирование уже вынесено за пределы Битрикс24 и проводится на уровне сайта или продуктовой платформы. В таких случаях отключение встроенного модуля не влияет на процессы.

Wiki

Модуль Wiki исторически использовался для внутренней базы знаний и документации.

Однако он морально устарел и в большинстве проектов его заменяют более современным инструментом — встроенной Базой знаний Битрикс24 или внешними решениями.

Если Wiki не используется активно, его отключение не создаёт операционных рисков.

Документооборот

Классический модуль документооборота также относится к устаревающему функционалу и редко применяется в современных внедрениях.

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

• через бизнес-процессы Битрикс24,
• с использованием автоматизированных рабочих мест,
• через встроенный кадровый электронный документооборот (КЭДО),
• либо с помощью специализированных систем ЭДО.

Поэтому отключение старого модуля документооборота чаще всего не затрагивает ключевые бизнес-процессы.

Практический вывод

В большинстве Enterprise-проектов переход на PostgreSQL не приводит к потере критичной функциональности. Часть модулей устарела, часть давно заменена внешними сервисами, а часть просто не используется.

Главное — до миграции провести аудит: определить, какие функции действительно задействованы в работе бизнеса, а какие существуют “по умолчанию”, но не влияют на процессы.

Часто задаваемые вопросы о миграции Битрикс24 на PostgreSQL

Можно ли перенести Битрикс24 с MySQL на PostgreSQL?

Да. Коробочная версия Битрикс24 Enterprise официально поддерживает PostgreSQL. Миграция выполняется через мастер или консольные инструменты с предварительным тестированием на копии портала.

Нужна ли отдельная лицензия для PostgreSQL?

Да. Для работы на PostgreSQL требуется соответствующая редакция лицензии Enterprise. Перед началом работ нужно проверить ключ и поддержку СУБД.

Сколько длится миграция Битрикс24 на PostgreSQL?

Зависит от объёма базы данных и инфраструктуры.
Ориентиры:

• до 10 ГБ — 1–3 часа,
• 10–50 ГБ — 3–8 часов,
• 50+ ГБ — рассчитывается индивидуально.

Большую часть времени занимает перенос данных.

Сколько часов простоя потребуется?

В боевом режиме портал обычно недоступен на время финального переноса и переключения. В среднем — от 1 до 6 часов. При грамотной подготовке простой минимизируется.

Можно ли выполнить миграцию без остановки портала?

Полностью без простоя — нет. Можно сократить время недоступности за счёт тестовой миграции и финального короткого окна переключения.

Нужно ли переписывать кастомный код?

Если используются прямые SQL-запросы — возможно, да. PostgreSQL строже к типам данных, GROUP BY и функциям. Кастомные модули и отчёты нужно тестировать отдельно.

Какие модули Битрикс24 не работают на PostgreSQL?

Могут быть недоступны отдельные модули аналитики, A/B-тестирования, рекламы и устаревшие инструменты. Перед миграцией обязательно проводится аудит используемого функционала.

Станет ли Битрикс24 работать быстрее на PostgreSQL?

Не обязательно. PostgreSQL — это не ускоритель, а инфраструктурная альтернатива. Производительность зависит от нагрузки и настройки.

Можно ли откатиться обратно на MySQL?

Да, если заранее подготовлен бэкап и сценарий отката. Именно поэтому перед миграцией всегда делается полный резервный снимок базы и файлов.

Когда переход на PostgreSQL действительно оправдан?

Коротко: если есть требования ИБ или импортозамещения, корпоративный стандарт это PostgreSQL, портал входит в общую архитектуру кластера, требуется унификация инфраструктуры.

Если MySQL стабильно работает и требований нет — миграция может быть избыточной.

Какие основные риски миграции?

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

Большинство рисков снимаются предварительным аудитом.

Нужна ли настройка PostgreSQL после переноса?

Да, обязательно. Необходимо настроить память, autovacuum, мониторинг, проверить индексы и статистику. Без этого возможна деградация через несколько месяцев.

Итог

Миграция Битрикс24 с MySQL на PostgreSQL — это инфраструктурный проект, который требует аудита, тестирования и точной настройки. При грамотном подходе переход проходит предсказуемо и без потери данных. При попытке сделать его «напрямую» — риски простоев и ошибок значительно возрастают.

Специалисты компании «Цифровой Элемент» выполняют миграцию коробочного Битрикс24 Enterprise под ключ: от оценки целесообразности и подготовки стенда до переноса и оптимизации PostgreSQL под реальную нагрузку.

Если вы рассматриваете переход на PostgreSQL — обратитесь к нам за консультацией. Мы поможем реализовать миграцию безопасно и без лишних рисков для бизнеса.

Статьи по теме:

• База знаний в Битрикс24: как создать и использовать для повышения эффективности работы
• Интеграция и настройка почты в Битрикс24
• Перенос и создание сайта на 1С-Битрикс: с WordPress, Tilda и других CMS