Supabase — не “Firebase без боли”: где он экономит, а где превращается в свой мини-облако

Supabase — не “Firebase без боли”: где он экономит, а где превращается в свой мини-облако

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

Что обычно забывают в TCO:
— Postgres тут не магия, а центр всей системы: индексы, бэкапы, ротация, репликация и контроль нагрузки остаются вашей заботой.
— Auth и политики доступа экономят время на MVP, но потом требуют аккуратной схемы прав, иначе запросы и RLS превращаются в квест.
— Realtime и storage хороши для типовых сценариев, но интеграции, очереди и медиа-пайплайн всё равно часто уезжают во внешний сервис или отдельный воркер.

Self-host имеет смысл, если вам нужен полный контроль над данными, сетями и доступом к Postgres, а также если команда уже умеет сопровождать инфраструктуру без паники при каждом инциденте. SaaS-формат чаще выигрывает, когда важнее скорость запуска, чем право собрать себе ещё один слой операционных задач.

Если продукт растёт, сравнивайте Supabase не с «бесплатно», а с ценой времени devops, схемой бэкапов и тем, сколько кастомной логики вы уже повесили на платформу. Чем больше уникальных правил, тем быстрее «простая сборка» становится дорогим компромиссом.