Лицензии Oracle и MS SQL Server дорожают, а условия поддержки ужесточаются. Госзаказчики и крупный бизнес всё чаще спрашивают: что будет, если уйти на PostgreSQL или другую открытую СУБД? Вопрос не в идеологии. Вопрос в деньгах, сроках и рисках простоя. Разберём, как считать миграцию честно – до того, как подписан первый акт.

Откуда берутся риски

Главный риск миграции – не сама СУБД, а код вокруг неё. Хранимые процедуры на PL/SQL или T-SQL, триггеры, специфичные типы данных, иерархические запросы CONNECT BY, аналитические функции – всё это придётся переписывать. Чем больше бизнес-логики вы загнали в базу, тем дороже выход.

Второй пласт рисков – интеграции. Драйверы, ORM, отчётные системы, ETL-процессы завязаны на конкретный диалект SQL и поведение оптимизатора. После переключения запросы, которые работали миллисекунды, могут начать тормозить из-за другого плана выполнения.

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

Как считать стоимость

Стоимость лицензий – лишь верхушка. Полная смета миграции складывается из четырёх частей:

  • Аудит и инвентаризация. Сколько объектов в схеме, сколько строк кода в процедурах, какие фичи СУБД задействованы. Без этого любая оценка – пальцем в небо.
  • Переписывание и адаптация. Процедуры, триггеры, запросы с проприетарными конструкциями. Здесь уходит до 60% бюджета проекта.
  • Тестирование. Функциональное, нагрузочное, регрессионное. Сверка результатов запросов на старой и новой базе строка в строку.
  • Перенос и переключение. Окно простоя, репликация, план отката.

Считайте не разовую экономию на лицензиях, а совокупную стоимость владения на три-пять лет. Открытая СУБД снимает лицензионные платежи, но требует компетентного сопровождения. Если такой экспертизы внутри нет – закладывайте поддержку в бюджет. Опыт перехода госсектора на открытые платформы мы описывали в материале про Linux и open source в госорганах.

Чем снизить риск

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

Где возможно, выносите бизнес-логику из базы в сервисный слой приложения – тогда смена СУБД перестаёт быть катастрофой и превращается в замену драйвера. Этот принцип мы разбирали в заметке про сервисную декомпозицию монолитов: чем тоньше связь приложения с конкретной базой, тем дешевле любая будущая миграция.

Обязательно стройте автоматизированную сверку данных и результатов запросов. Ручная проверка на больших объёмах нереалистична и пропускает ошибки.

Вывод

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