Supabase как OSS-бэкенд: где он экономит неделю, а где тихо съедает поддержку

Supabase как OSS-бэкенд: где он экономит неделю, а где тихо съедает поддержку

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

Но self-host тут надо считать как проект, а не как пакет. Вам нужны Postgres-админка, бэкапы, мониторинг, миграции, секреты, логирование, обновления контейнеров и человек, который понимает, почему auth, storage и база начали расходиться по поведению. Если у команды уже есть нормальный DevOps, Supabase может заменить несколько SaaS и сократить зоопарк. Если DevOps нет — получится ещё один слой, который надо обслуживать 24/7.

Хороший сценарий:
— быстрый запуск админок, кабинетов, простых CRM и лендингов с авторизацией;
— один источник данных вместо «таблицы + отдельный API + отдельный файл-сторедж»;
— команды, где Postgres уже стандарт, а не чужая экзотика.

Плохой сценарий:
— сложная бизнес-логика, которую хочется запихнуть в SQL и edge-функции;
— высокий риск жёсткой связанности с платформой;
— проекты, где любые простои и регрессии дороже экономии на SaaS.

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