<b>Supabase ломают не на старте, а когда забывают про границы между app и DB</b>

<b>Supabase ломают не на старте, а когда забывают про границы между app и DB</b>

За неделю в репах: у Supabase чаще всего всплывают не «проблемы с Postgres», а архитектурные ошибки. Таблицы начинают обслуживать всё подряд: auth, бизнес-логику, файлы, фоновые задачи. Потом команда удивляется, почему миграции страшно трогать, а запросы разрастаются как монолит.

Есть наблюдение которое стоит проверить: если проект маленький, Supabase даёт быстрый старт. Но как только появляется несколько клиентов, роли, приватные данные и фоновые джобы, надо заранее разделять:
— что живёт в таблицах и RLS;
— что уходит в edge functions или backend;
— что нельзя отдавать в клиент вообще.
Иначе «удобный BaaS» превращается в набор скрытых зависимостей.

Ещё одна типовая ловушка — полагаться на auto-generated API как на основной контракт. Для прототипа это ок, для долгой жизни проекта лучше считать схему источником данных, а не единственным интерфейсом. Иначе любое переименование поля бьёт по фронту, тестам и интеграциям сразу.

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