Требование о переходе на отечественное ПО перестало быть рекомендацией. Постановление № 1236 закрепило приоритет российского софта при госзакупках, а реестр Минкомсвязи задаёт перечень допустимых продуктов. Для баз данных это означает уход от Oracle и Microsoft SQL Server в сторону систем на ядре PostgreSQL – Postgres Pro, реестровых сборок и open-source-версии. Разберём, как спланировать миграцию так, чтобы она не превратилась в многолетнюю заморозку разработки.

С чего начинается миграция

Сначала – инвентаризация. Посчитайте объём данных, число хранимых процедур, триггеров, представлений и заданий планировщика. Именно серверная логика, а не сами таблицы, определяет трудоёмкость проекта. Перенос схемы и данных автоматизируют ora2pg и pgloader, но процедурный код на PL/SQL или T-SQL переписывают на PL/pgSQL вручную: автоконвертеры покрывают типовые конструкции, а специфику оптимизатора и системные пакеты вроде DBMS_* приходится переосмысливать.

Отдельно проверьте прикладной слой. Запросы с проприетарными функциями, иерархические CONNECT BY, оконные конструкции и подсказки оптимизатору ведут себя в PostgreSQL иначе. Соберите полный список SQL, который уходит из приложений, и прогоните его на тестовом контуре до начала переноса. Так вы получите реальную оценку, а не догадку.

Данные, логика и производительность

Перенос делят на три потока. Первый – структура и данные: типы приводят к PostgreSQL (NUMBER к numeric, NVARCHAR к text, даты – аккуратно, с учётом часовых поясов). Второй – бизнес-логика: процедуры, функции, пакеты. Третий – производительность: PostgreSQL требует другой стратегии индексов, регулярного VACUUM и ANALYZE, продуманной настройки work_mem и shared_buffers.

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

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

Параллельная работа и приёмка

Резкое переключение в проде – главный источник аварий. Запустите старую и новую СУБД параллельно, наладьте репликацию изменений и сверяйте результаты на одинаковых запросах. Этап двойной записи длится недели, иногда месяцы, но именно он отделяет управляемый переход от ночного аврала с откатом.

Автоматизируйте проверки. Подход к воспроизводимым пайплайнам, который мы описывали в статье про вывод ML-моделей в production, работает и здесь: каждый прогон миграции должен быть скриптом, а не ручной последовательностью кликов. Регрессионные тесты на данных и сверка контрольных сумм закрывают вопрос «а всё ли доехало».

Помните и про команду. После перехода на стек разработчики и DBA должны уверенно владеть PostgreSQL. Документация, ретроспективы и базовое обучение здесь окупаются быстрее любых лицензий. Эксперименты с автогенерацией текста и кода, о которых мы писали ранее, пока остаются вспомогательным инструментом – основную нагрузку несут инженеры.

Вывод

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