Supabase ломается не в Postgres, а в том, как его начинают использовать как Firebase-замену

Supabase ломается не в Postgres, а в том, как его начинают использовать как Firebase-замену

Supabase хорош там, где нужен быстрый старт: Auth, Postgres, Storage, Edge Functions, realtime в одном месте. Но типовая ошибка одна — тащить в него всю бизнес-логику и считать, что “всё уже бэкенд”. На практике это приводит к размытым границам: часть правил в SQL, часть в RLS, часть в функциях, а часть — в клиенте.

За что Supabase обычно любят:
— быстро поднимается MVP без отдельного DevOps-слоя
— Postgres остаётся нормальной базой, а не чёрным ящиком
— RLS позволяет закрывать доступ к данным на уровне строк

Где чаще всего начинают терять контроль:
— сложные сценарии авторизации пытаются уложить только в RLS
— логику платежей, триггеров и интеграций держат в клиенте
— забывают, что realtime и storage тоже надо проектировать, а не включать “на всякий случай”

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

Итог простой: Supabase ускоряет старт, но дисциплина схемы, RLS и границ ответственности важнее самого сервиса.