Как переехать с одной СУБД на другую (например, MySQL → PostgreSQL)?

Что значит "переехать с одной СУБД на другую"

Это не только выгрузка и загрузка строк. При миграции нужно перенести:

• схему: таблицы, столбцы, типы данных, индексы, ограничения, внешние ключи;

• данные;

• SQL‑запросы и диалектные особенности: LIMIT/OFFSET, функции строк, даты, UPSERT, работа с NULL, автонумерация и т.п.;

• хранимые процедуры, триггеры, представления, события;

• код приложения, ORM‑модели, миграции и интеграции с внешними сервисами.

Почему это сложно

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

Типичный план миграции

1. Инвентаризация — понять, какие таблицы, запросы, процедуры, отчёты, ETL‑джобы и сервисы завязаны на текущую СУБД.

2. Оценка несовместимостей — составить список различий в типах данных, функциях, синтаксисе, индексах, автоинкременте, транзакциях, уровне изоляции, collations и т.п.

3. Перенос схемы — создать эквивалентные таблицы и ограничения в новой СУБД, при необходимости пересмотреть типы данных и денормализацию/нормализацию.

4. Адаптация SQL и кода — переписать запросы, хранимую логику, ORM‑модели, raw SQL, тесты.

5. Перенос данных — выполнить бэкап/restore, использовать ETL, репликацию или специальные миграционные инструменты.

6. Проверка — прогнать интеграционные тесты, сверить количество строк, контрольные выборки, отчёты и бизнес‑метрики.

7. Cutover — переключить приложение на новую СУБД, обычно постепенно: через shadow traffic, read‑only режим, canary или поэтапный запуск.

На что чаще всего натыкаются

• разные типы данных и ограничения: например, BOOLEAN, UUID, JSONB, ENUM, AUTO_INCREMENT vs SERIAL/IDENTITY;

• отличия в SQL-диалектах и функциях, например в работе с датами, строками и оконными функциями;

• различия в поведении транзакций, блокировок, уровней изоляции и дедлоков;

• неявные зависимости в приложении: предположения о порядке строк, сравнении NULL, регистре, кодировках и collation.

Когда это делать особенно осторожно

Особенно рискованно переносить системы с высокой нагрузкой и сложной доменной логикой. Если в приложении много сырого SQL, специфичных для СУБД функций или триггеров, объём работ резко растёт. В таких случаях переезд часто делают итеративно: сначала создают совместимый слой, потом постепенно переводят отдельные сервисы и запросы.

Как ответить на собеседовании

Переезд с одной СУБД на другую — это проект по миграции схемы, данных и кода с учётом различий между диалектами и поведением СУБД. Я бы описал его как последовательность шагов: инвентаризация зависимостей, проектирование целевой схемы, адаптация SQL и приложения, перенос данных, тестирование и поэтапный cutover. Для примера можно сказать, что при переходе с MySQL на PostgreSQL придётся отдельно проверить типы данных, автоинкремент, UPSERT, транзакции и все raw SQL-запросы.