Supabase удобно брать как старт, но миграцию потом ломают не таблицы, а привычки

Supabase удобно брать как старт, но миграцию потом ломают не таблицы, а привычки

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

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

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

Отдельный плюс Supabase — он хорошо переносится в разговоре с командой: Postgres остаётся Postgres, а значит проще нанимать, ревьюить схему и выносить часть логики наружу без полной переписки продукта.

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