<b>Supabase хорош как стартовый backend, но ломается там, где его принимают за магию</b>

<b>Supabase хорош как стартовый backend, но ломается там, где его принимают за магию</b>

Supabase часто берут ради auth, Postgres и storage в одном месте. Для MVP это удобно: меньше склейки, быстрее первый релиз, проще отдать проект фронтенд-команде без отдельного DBA. Но архитектурная ошибка тут одна — считать, что «всё уже есть» и не планировать границы нагрузки.

За неделю в репах чаще всего всплывают три проблемы:
— auth и RLS настроены «на глаз», а потом доступы начинают течь между ролями;
— storage используют как CDN, хотя это не его роль;
— realtime и функции лепят в критический путь, не проверяя, что будет при росте запросов.

<b>На что смотреть до продакшена:</b> отдельные схемы под публичные и служебные данные, явные политики RLS, миграции как обязательный этап, а не ручной ритуал. Если проект живёт дольше MVP, сразу фиксируйте, где у вас обычный SQL, а где уже бизнес-логика вне БД.

Еще одна частая ловушка — переносить в Supabase всё подряд, включая тяжёлые джобы, очереди и аналитику. Для этого лучше держать отдельный worker, а Supabase оставить тем, в чём он силён: данные, доступ, быстрый API-слой.

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