Oracle и Microsoft приостановили продажи и продление лицензий в России. Новые узлы кластеров теперь не лицензировать легально, обновления безопасности не приходят, техподдержка по корпоративным контрактам замолчала. Для банков, промышленности и госорганов это не абстрактный риск, а вопрос ближайших кварталов. PostgreSQL стала очевидной заменой: открытая лицензия, отечественные сборки в реестре и зрелая экосистема. Разберём, как мигрировать промышленную СУБД без остановки бизнеса.

Почему PostgreSQL, а не «подождём»

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

PostgreSQL закрывает большую часть корпоративных сценариев: транзакционная нагрузка, аналитика, geospatial, JSON. Отечественные сборки (Postgres Pro и другие) внесены в реестр российского ПО, поставляются с поддержкой на русском и SLA. Для госзакупок и грантов это закрывает формальное требование к происхождению продукта.

Что реально болит при миграции

Перенос данных – самая простая часть. Боль концентрируется в трёх местах.

Серверная логика. PL/SQL и T-SQL не переносятся в PL/pgSQL автоматически. Хранимые процедуры, триггеры, пакеты Oracle и специфика автоинкремента MS SQL требуют ручной переработки. Инструменты вроде ora2pg и pgloader снимают рутину, но 20–30% кода всё равно переписывают вручную.

Типы и поведение. Различия в NULL-сортировке, пустых строках Oracle, иерархических запросах CONNECT BY, оконных функциях и форматах дат ломают результаты тихо – без ошибки, но с неверными данными. Каждый такой случай ловится только тестами.

Приложения сверху. ORM, прямые SQL-запросы из кода, ETL-потоки и BI-отчёты завязаны на диалект исходной СУБД. Миграция базы без ревизии приложений даёт работающую базу и неработающую систему.

Поэтому «перелить таблицы» – лишь малая часть миграции корпоративной СУБД на PostgreSQL, за которой стоит отдельный контур тестирования серверной логики и зависимых приложений.

Как мы ведём проект

Порядок отработан на промышленных внедрениях.

  1. Аудит. Инвентаризируем объекты схемы, объём данных, серверную логику, зависимые приложения и интеграции. На выходе – карта совместимости и оценка трудоёмкости.
  2. Целевая архитектура. Выбираем сборку PostgreSQL из реестра, проектируем репликацию, резервное копирование и отказоустойчивость под вашу нагрузку.
  3. Конвертация схемы и кода. Автоматизируем переносимое, переписываем процедурную логику, согласуем типы данных.
  4. Параллельный прогон. Гоняем старую и новую СУБД на боевых данных, сверяем результаты запросов и производительность под нагрузкой.
  5. Переключение. Переходим в окно с минимальным трафиком, держим план отката наготове.

Сроки зависят от объёма серверной логики, а не от размера данных. Типовая корпоративная система – это от трёх до девяти месяцев. Чем раньше начат аудит, тем больше пространства для манёвра до истечения текущих лицензий.

Вывод

Миграция на PostgreSQL – управляемый инженерный проект, а не аврал, если начать заранее. Главный риск лежит не в данных, а в серверной логике и зависимых приложениях, и закрывается он тестированием на боевых сценариях. Как мы отмечали в итогах 2021 года, переход на открытые платформы был трендом и до санкций – сейчас он стал необходимостью. Начните с аудита: он даёт честную оценку сроков и бюджета без обязательств по дальнейшим работам.