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

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

PlanetScale любят за быстрый старт, ветки и удобный workflow для MySQL. Но в проде сервис почти всегда упирается не в «как создать базу», а в то, как приложение переживает ограничения вокруг него.

Сразу проверь 4 вещи:
— есть ли в коде жёсткая зависимость от MySQL-фич, которые плохо живут в serverless-архитектуре;
— умеет ли ORM работать без долгих транзакций и блокировок;
— не полагается ли приложение на миграции, которые требуют `ALTER TABLE` в лоб;
— есть ли план отката, если схема поехала и ветка не совпала с prod.

Отдельная ловушка — соединения. Если бэкенд раздаёт много коротких коннектов, база может выглядеть «лёгкой» только на диаграмме. В реальности начинают всплывать таймауты, пуллинг и странные ошибки на пике.

Ещё один момент — аналитика и отчёты. Если команда привыкла делать тяжёлые SQL-запросы прямо в боевой базе, лучше заранее вынести это в отдельный контур или хотя бы ограничить такие сценарии. Иначе удобство веток быстро съедается нагрузкой.

PlanetScale хорошо подходит там, где важны скорость разработки и безопасные изменения схемы. Но перед выбором базы полезно ответить не «поднимется ли она», а «как мы будем жить после третьей миграции».