Уход Oracle и Microsoft с российского рынка превратил вопрос «мигрировать или нет» в вопрос «когда и как». Для госсектора дедлайны жёсткие: критическая информационная инфраструктура должна переходить на отечественное ПО, а PostgreSQL и его сертифицированные сборки (Postgres Pro) – основной кандидат. Проблема в том, что подрядчики обещают перенос «за месяц», а реальные проекты идут от полугода до полутора лет. Разберём, откуда берётся эта разница.

Где прячутся реальные сроки

Перенос самих таблиц и данных – самая простая часть, она занимает недели. Время съедает бизнес-логика. Хранимые процедуры на PL/SQL и T-SQL не переносятся автоматически: их переписывают под PL/pgSQL вручную, с проверкой каждого крайнего случая. У крупного заказчика таких процедур бывает несколько тысяч.

Грубая оценка по нашим проектам:

  • Аудит и инвентаризация – 3–6 недель. Никто не знает точно, что крутится в проде; половина процедур не вызывается годами.
  • Перенос схемы и данных – 2–4 недели на ETL и сверку.
  • Переписывание логики – от 2 до 9 месяцев в зависимости от объёма.
  • Тестирование и нагрузочные испытания – 1–3 месяца, и эту фазу почти всегда недооценивают.

Сроки сжимаются, если приложение работает через ORM и не использует специфику СУБД. Растягиваются – когда логика зашита в БД, а исходников приложения уже нет.

Подводные камни, которые видны не сразу

Диалекты SQL. Иерархические запросы Oracle (CONNECT BY), функции вроде DECODE, NVL, синтаксис внешних соединений (+) – всё это требует ручного перевода. T-SQL приносит свои сюрпризы: оконные функции, обработка NULL, поведение транзакций отличаются.

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

Типы данных и кодировки. NUMBER без точности, неявные приведения типов, разница в обработке пустой строки и NULL (в Oracle это часто одно и то же) – источник тихих ошибок, которые всплывают в отчётности через месяцы.

Высокая доступность. Привычные RAC или AlwaysOn заменяются связкой Patroni, репликации и балансировщиков. Архитектуру отказоустойчивости проектируют заново, а не «портируют».

Как снизить риск

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

Отдельно оцените, что вы переносите. Часть legacy-логики проще не мигрировать, а переосмыслить – особенно если вокруг данных строится аналитика. Мы подробно разбирали, как меняется ландшафт аналитических инструментов, в обзоре карты рынка BI. А если на исторические данные планируется навесить корпоративный поиск или ассистента, имеет смысл сразу заложить структуру под базу знаний с RAG, пока схема ещё на столе.

Вывод

Миграция на PostgreSQL – не «перенос файлов», а инженерный проект со сроком от полугода. Главные риски лежат не в данных, а в бизнес-логике, производительности и тестировании. Реалистичная оценка на старте дешевле, чем сорванный дедлайн по КИИ, поэтому начинать стоит с плана перехода на PostgreSQL с честными сроками под вашу систему.