<b>PlanetScale удобен до первого миграционного сюрприза: как не попасть в ловушку</b>

<b>PlanetScale удобен до первого миграционного сюрприза: как не попасть в ловушку</b>

PlanetScale любят за простую стартовую схему: подключил базу, работаешь через branching, не ломаешь прод на тестовых миграциях. Но у этого комфорта есть цена — архитектуру проекта надо понимать заранее, а не после роста.

— Не планируй на него как на «обычный MySQL без ограничений». Внешне всё знакомо, но часть привычных паттернов с FK, сложными транзакциями и жёсткой связностью лучше сразу проверить на своём кейсе.
— Если у тебя много связей между таблицами и сильная зависимость от каскадов, заранее прогони сценарии ручками. Иначе миграция схемы может оказаться дороже, чем переезд на другую БД.
— Для команд с частыми изменениями схемы сильная сторона PlanetScale — безопасные изменения без остановки продакшена. Это особенно полезно, когда несколько разработчиков одновременно трогают структуру данных.
— Смотри не только на базу, но и на весь путь миграции: ORM, генерация схемы, сиды, тестовые окружения, бэкапы. Обычно боль начинается не в SQL, а в связке вокруг него.

Если проект уже живёт на жёстких реляционных связях, PlanetScale надо выбирать осознанно: как инструмент для удобного роста, а не как универсальную замену любой MySQL-инфраструктуре.