Supabase ломается не на старте, а когда в проекте смешивают Auth, RLS и публичный API

Supabase ломается не на старте, а когда в проекте смешивают Auth, RLS и публичный API

Supabase удобен тем, что дает Postgres, авторизацию, storage и edge-функции в одном месте. Но типичная ошибка — считать его просто “базой с фронтом”. На деле основная сложность появляется в праве доступа: если правила RLS не продуманы сразу, данные либо слишком открыты, либо начинают “магически” пропадать.

Что проверять до запуска:
• все таблицы с пользовательскими данными защищены RLS;
• политики пишутся от реальных сценариев: владелец записи, команда, админ;
• публичный anon key не дает больше, чем нужно фронту;
• service role не уезжает в клиентский код и не лежит в репозитории;
• storage-бакеты и функции имеют те же ограничения, что и таблицы.

Еще один частый провал — миграции. Когда схема меняется вручную через SQL-редактор, а потом кто-то забывает перенести это в миграцию, проект быстро расходится между окружениями. Для команды это почти гарантированный источник багов: локально работает, на staging нет, в проде уже не повторить.

По деньгам и архитектуре Supabase хорош для MVP и среднего продукта, пока вы контролируете запросы и объемы. Но как только начинаются сложные joins, тяжелые отчеты и много фоновой логики, нужно заранее думать о кэше, вынесении задач и лимитах на хранение и трафик.

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