Planetscale удобен, пока не упираешься в ограничения схемы и auth-логики

Planetscale удобен, пока не упираешься в ограничения схемы и auth-логики

Если строишь SaaS на supabase и postgres, смотри не на «масштабируемость», а на то, как база переживает реальную продуктовую нагрузку:
— есть ли в проекте жёсткие foreign key и каскады;
— нужны ли транзакции через несколько таблиц;
— завязан ли доступ на rls и роли;
— придётся ли делать сложные миграции без простоя.

Planetscale хорош там, где схема меняется аккуратно, а запросы читаются проще, чем пишутся. Но как только появляются multi-tenant-логика, auth, row-level security и аналитические выборки, цена удобства часто всплывает в обходных решениях: часть правил уезжает в код, часть — в сервисный слой, часть — в ручные проверки.

Для арб-инструментов и B2B-панелей важнее предсказуемость: понятные транзакции, индексы под реальные фильтры, контроль доступа на уровне postgres, а не только в приложении. Тогда pgvector, очереди, фоновые джобы и отчёты живут в одной модели данных, без лишней магии.

Если нужен быстрый старт — Planetscale может быть нормальным промежуточным выбором. Если же продукт строится вокруг auth, rls и сложной доменной схемы, лучше сразу проектировать под postgres так, чтобы база оставалась источником истины, а не просто хранилищем.