<b>PlanetScale хорош, пока вы не упрётесь в схему и миграции</b>

<b>PlanetScale хорош, пока вы не упрётесь в схему и миграции</b>

У PlanetScale сильная сторона простая: MySQL без боли вокруг железа, с ветками базы, безопасными deploy requests и нормальным workflow для команды. Для старта и среднего продукта это снимает массу рутины: не надо руками городить окружения, копии и страшные миграции ночью.

Но есть три места, где новички чаще всего ломаются:
— ждут, что база будет вести себя как «обычный MySQL с магией»;
— втаскивают ORM-миграции, которые требуют прямого ALTER в проде;
— не проверяют, как у них устроены foreign keys, транзакции и запросы с большим числом join’ов.

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

Есть наблюдение которое стоит проверить: большинство проблем с PlanetScale — не от самой базы, а от привычек команды. Когда миграции пишут как попало и не тестируют запросы на копии схемы, любой managed-сервис начинает «разочаровывать».

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