Supabase — не «замена Firebase», а свой бэкенд-скелет, если умеешь считать поддержку

Supabase — не «замена Firebase», а свой бэкенд-скелет, если умеешь считать поддержку

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

Но «open source» тут не равно «дёшево». Самохост тянет за собой PostgreSQL, бэкапы, миграции, мониторинг, очереди, доступы, секреты и обновления. Если нет человека, который это любит и умеет, экономия на SaaS быстро съедается часами девопса и разбором инцидентов.

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

Когда платить SaaS:
— у вас маленькая команда и нет выделенного ops;
— критичны SLA, резервирование и предсказуемая поддержка;
— проекту нужен не «конструктор», а один ответственный вендор.

Главная ошибка — считать только сервер. В TCO Supabase надо закладывать время на бэкапы, права, восстановление после поломок и контроль схемы. Иначе экономия на старте превращается в технический долг уже на втором релизе.