Supabase: когда Postgres+Auth+Storage закрывают MVP, а когда превращаются в долгий self-host

Supabase: когда Postgres+Auth+Storage закрывают MVP, а когда превращаются в долгий self-host

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

Но OSS-этикетка тут не значит «поставил и забыл». Self-host Supabase — это не один контейнер, а набор сервисов, которые надо мониторить, бэкапить, обновлять и разруливать между собой. Самая частая ошибка — считать только сервер, забывая про время на миграции схем, права доступа, почтовую доставку, очереди и восстановление после падения.

Когда брать:
— нужен быстрый старт с Postgres-ядром и готовой auth-обвязкой;
— важны SQL, RLS и контроль над данными;
— есть devops, который не исчезнет после первого деплоя.

Когда лучше SaaS:
— команда маленькая и любая поломка бэкенда останавливает продажи;
— нужен предсказуемый SLA и меньше операционки;
— нет желания тащить ещё один слой инфраструктуры ради экономии на лицензии.

Если нужен каркас для MVP или внутреннего сервиса — Supabase очень удобен. Если продукт уже держит трафик и деньги, считайте не стоимость сервера, а стоимость ночных инцидентов и поддержки 🧩