Лицензии Oracle и Microsoft SQL Server дорожают, а курс рубля делает их непредсказуемой статьёй бюджета. Госзаказчики получают всё более жёсткие требования к независимости от иностранного ПО. На этом фоне PostgreSQL перестал быть «базой для энтузиастов»: версия 9.3 закрывает большинство задач корпоративного уровня – материализованные представления, оконные функции, JSON-тип, потоковую репликацию. Вопрос больше не в том, способна ли свободная СУБД заменить проприетарную, а в том, как провести переход без остановки бизнеса. Разберём первые шаги.

Сначала инвентаризация, потом миграция

Не начинайте с переноса данных. Начните с честной описи того, что у вас работает. Соберите список баз, их объём, нагрузку, SLA и – главное – зависимости приложений от конкретной СУБД.

Чаще всего болит не схема таблиц, а логика, зашитая в базу:

  • хранимые процедуры на PL/SQL или T-SQL;
  • триггеры и пакеты;
  • специфичные функции (CONNECT BY, ROWNUM, иерархические запросы);
  • ETL-задания и отчёты, жёстко привязанные к диалекту SQL.

Перенос таблиц и данных – задача на дни. Перенос бизнес-логики – на месяцы. Поэтому ранжируйте системы по сложности и критичности. Начинайте с того, где зависимость от диалекта минимальна: справочники, витрины отчётности, внутренние сервисы без жёсткого SLA. Ядро ERP с тысячами процедур оставьте на финал, когда команда наберёт опыт.

Этот подход – продолжение разговора об импортозамещении как управляемом процессе, а не разовом авральном проекте.

Что переносится автоматически, а что руками

Структуру и данные мигрируют инструменты. Для Oracle работает ora2pg, для MS SQL – собственные скрипты выгрузки плюс конвертеры типов. Они переносят таблицы, индексы, ограничения и сами данные, оценивают объём ручной доработки и формируют отчёт о несовместимостях.

Чего инструменты не сделают:

  • Процедурный код. PL/SQL и T-SQL переписываются на PL/pgSQL вручную. Автоконвертеры дают черновик, но логику транзакций и обработку ошибок проверяет человек.
  • Типы данных. NUMBER без точности, DATE с временем, национальные строки – каждый случай требует решения, а не слепого маппинга.
  • Особенности оптимизатора. Планы запросов в PostgreSQL строятся иначе. Часть «быстрых» в Oracle запросов придётся переписать и заново проиндексировать.

Закладывайте в план этап нагрузочного тестирования на реальных объёмах. База, которая летает на десяти тысячах строк, способна встать на десяти миллионах.

Архитектура и команда

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

Команде нужны компетенции в PostgreSQL: настройка autovacuum, планирование репликации, тюнинг shared_buffers и work_mem. Это вопрос не только технологии, но и зрелого подхода к работе с open source в корпоративном контуре: поддержка, обновления, безопасность.

Хранилища и платформы данных и BI на PostgreSQL проектируются итеративно: от пилота на одной некритичной системе до переноса ядра под нагрузкой.

Вывод

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