Supabase как OSS-база: где он реально заменяет SaaS, а где быстро вырастает в свой мини-стек

Supabase как OSS-база: где он реально заменяет SaaS, а где быстро вырастает в свой мини-стек

Supabase часто берут как «Firebase, только свой». На практике это Postgres + Auth + Storage + Realtime + Edge Functions в одном интерфейсе. Для MVP и внутренних кабинетов это удобно: меньше склейки сервисов, быстрее старт, проще дать бэкенд и фронт на одну схему данных.

Но «одна панель» не отменяет TCO. Self-host упрётся не в запуск контейнеров, а в рутину: бэкапы Postgres, миграции, контроль прав, наблюдаемость, очереди, object storage, TLS, секреты и восстановление после ошибки. Если команда не умеет держать базу и фоновые задачи, Supabase легко превращается в ещё один слой, который надо объяснять новому девопсу.

Когда брать:
— нужен быстрый старт с Postgres-first архитектурой;
— важны auth, storage и API без сборки зоопарка;
— есть человек, который отвечает за БД и деплой.
Когда платить SaaS:
— нет ресурса на поддержку базы и инциденты;
— критичны SLA, аудит и предсказуемые апдейты;
— приложение растёт, и «починить потом» уже стоит дороже, чем подписка.

Главная ошибка — считать Supabase «готовой платформой без админа». Это хороший каркас, если вы готовы владеть Postgres как продуктом, а не просто кнопкой «deploy».