Лицензии Oracle и Microsoft SQL Server дорожают, а директива о переходе госорганов на отечественное ПО давит на бюджеты и сроки. PostgreSQL – рабочая альтернатива: открытый код, зрелая экосистема и российские сборки Postgres Pro, включённые в реестр. Но миграция СУБД редко сводится к переносу таблиц. Хранимые процедуры, диалекты SQL, типы данных и интеграции тянут за собой переделку приложения. Ниже – дорожная карта, которую мы применяем на проектах.
Аудит и оценка совместимости
Сначала инвентаризируем исходную базу. Считаем объекты: таблицы, представления, триггеры, хранимые процедуры на PL/SQL или T-SQL, задания планировщика, внешние ключи и материализованные представления. Отдельно фиксируем зависимости приложения – прямые SQL-запросы в коде, ORM-маппинги, отчётные системы.
Дальше оцениваем разрыв. PostgreSQL не понимает PL/SQL напрямую: пакеты Oracle, иерархические запросы CONNECT BY, автономные транзакции и последовательности требуют переписывания. T-SQL приносит свои сюрпризы – синтаксис TOP, временные таблицы, специфику работы с датами. Расширение orafce и язык PL/pgSQL закрывают часть разрыва, но не весь. Результат этапа – реестр объектов с пометкой «переносится автоматически / требует ручной переработки / переписывается заново» и честная оценка трудозатрат.
Перенос данных и кода
Схему конвертируем инструментами вроде ora2pg или pgloader, но автогенерацию всегда вычитываем вручную: типы NUMBER, DATE, CLOB ложатся на PostgreSQL неоднозначно, и ошибка в точности или часовом поясе всплывёт уже в продакшене. Хранимую логику переписываем на PL/pgSQL, заодно пересматривая то, что в исходной СУБД работало по инерции.
Данные переносим в два прохода: первичная массовая загрузка, затем догрузка дельты перед переключением, чтобы минимизировать простой. Для крупных баз настраиваем логическую репликацию и держим обе системы синхронными до момента отсечки.
При проектировании целевой схемы учитывайте требования к защите информации – шифрование, разграничение доступа, журналирование. Если система обрабатывает персональные данные или работает с удалёнными подключениями, заложите контуры безопасности сразу, а не после запуска: мы разбирали это в материале про защиту данных при удалённой работе.
Тестирование и переключение
Без полноценного нагрузочного и функционального тестирования миграцию закрывать нельзя. Сверяем результаты запросов на старой и новой базе построчно, прогоняем регрессию приложения, замеряем производительность под боевым профилем нагрузки. PostgreSQL иначе строит планы выполнения – индексы и статистику почти всегда приходится донастраивать.
Переключение планируем на технологическое окно с заранее прописанным сценарием отката. Первые недели держим возможность вернуться на прежнюю СУБД, пока новая среда не подтвердит стабильность.
Зачем это бизнесу и госсектору
Переход на PostgreSQL снимает зависимость от валютных лицензий и санкционных рисков, а для госзаказчиков закрывает требование закупать ПО из реестра – о его логике мы писали в разборе реестра российского ПО. Для ИТ-компаний переход на отечественный стек вписывается и в новые налоговые условия из ИТ-манёвра.
Вывод
Миграция на PostgreSQL – это проект переработки приложения, а не разовый экспорт данных. Цена ошибки растёт с объёмом базы и сложностью логики, поэтому начинать стоит с аудита и пилота на изолированном контуре, а полноценную миграцию на PostgreSQL под ключ разворачивать уже от подтверждённой на пилоте оценки совместимости до сопровождения после запуска.
