Supabase ломается не на старте, а когда проекту нужен порядок в данных

Supabase ломается не на старте, а когда проекту нужен порядок в данных

Supabase удобен ровно до момента, пока вы не начинаете смешивать auth, storage, SQL и бизнес-логику в один слой. После этого растут не фичи, а количество неявных зависимостей.

Что обычно забывают проверить до релиза:
• RLS-политики на все таблицы, а не только на «основные»
• кто может читать storage-объекты по прямой ссылке
• какие запросы идут через client SDK, а какие должны жить на сервере
• где у вас триггеры, которые делают магию, но потом мешают миграциям

Ещё одна типовая ошибка — считать Postgres в Supabase «просто базой». На практике там быстро появляются фоновые задачи, edge-функции, webhooks и отдельные таблицы для аудита. Если не разделить зоны ответственности сразу, любое изменение схемы начинает ломать соседние сценарии.

Нормальная привычка: держать RLS как обязательный чек, миграции — только через репозиторий, а сервисные ключи — вне клиентского кода. И отдельно тестировать не happy path, а прямой доступ к таблицам и bucket’ам. Так Supabase остаётся ускорителем, а не копилкой скрытых багов.