Supabase удобно брать как backend-старт, но дорого обходится хаотичная схема

Supabase удобно брать как backend-старт, но дорого обходится хаотичная схема

За неделю в репах видно одно и то же: проект стартует на Auth + Postgres + Storage, а через месяц в базе уже нет порядка. Supabase хорош там, где нужен быстрый MVP, но его сила заканчивается, когда команда начинает лепить бизнес-логику прямо в SQL без правил именования, индексов и миграций.

Что проверить до первого продакшена:
— роли и RLS: кто реально может читать, писать и удалять;
— миграции: схема должна жить в репозитории, а не в ручных кликах;
— индексы на частые фильтры и связи, иначе Postgres быстро станет узким местом;
— Storage и signed URL: не держите публичные бакеты там, где есть приватные файлы.

Отдельно смотрите на архитектуру: Supabase удобно закрывает auth, realtime и простые CRUD-сценарии, но сложные фоновые задачи, очереди и тяжёлые интеграции лучше вынести наружу. Иначе проект начинает зависеть не от продукта, а от того, насколько аккуратно вы обходите ограничения платформы.

Есть наблюдение которое стоит проверить: чем раньше вы опишите, где заканчивается клиент, где живут политики доступа и что считается источником правды, тем меньше шансов потом переписывать половину бэка. Supabase отлично ускоряет старт, если не делать вид, что он заменяет дисциплину в данных.