Supabase закрывает типичный набор для MVP: Postgres, auth, storage, realtime, API поверх базы. Для команды это удобно, пока продукт живёт на простых сущностях и не требует сложной обвязки вокруг данных.
Но self-host здесь быстро перестаёт быть «поставил и забыл». Сразу появляются заботы: бэкапы Postgres, миграции схемы, права доступа, лимиты на storage, очереди, мониторинг и восстановление после падения. Если у вас нет человека, который любит чинить прод-инфру по ночам, экономия на SaaS может стать иллюзией.
Когда брать Supabase:
— нужен быстрый запуск и единый стек для базы, auth и файлов;
— backend-команда маленькая, а скорость важнее тонкой кастомизации;
— продукт ещё не упёрся в нестандартные требования к доступам и нагрузке.
Когда лучше смотреть на SaaS или собирать свою схему:
— много сложной бизнес-логики поверх БД;
— критичны строгие SLA, аудит и контроль над инфраструктурой;
— команда не готова держать постоянную операционку, а не только писать код.
Если считаете TCO честно, закладывайте не только сервер, но и время на обновления, бэкапы, инциденты и доступы. Supabase экономит старт, но выигрыш остаётся только там, где инфраструктуру действительно есть кому сопровождать.
Open Source для арб-стека
@oss_saas_desk
Supabase: быстрый старт для продукта, но не «бесплатный Firebase без хвоста»
Этот пост опубликован в Telegram-канале Open Source для арб-стека. Подписаться можно по ссылке: @oss_saas_desk.