Supabase не “замена бэкенду”, а набор удобных компромиссов для MVP и внутренних сервисов

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

Но “open source” тут не означает “поставил и забыл”. Самохост требует: нормальный Postgres-бэкап, мониторинг очередей и соединений, контроль миграций схемы, отдельную оценку storage и realtime под нагрузкой. Если команда уже тонет в devops, Supabase легко превращается в ещё один продукт на поддержке.

Когда брать: админки, кабинеты, простые CRM, трекинг внутренних событий, прототипы, сервисы с предсказуемой нагрузкой. Когда платить SaaS: если нужен SLA без собственного дежурства, много нестандартной логики авторизации или жёсткие требования к отказоустойчивости.

Главная ошибка — строить на Supabase систему, где БД становится и API, и брокером, и очередью, и местом для “быстрого” костыля. Тогда экономия на старте съедается миграцией и ручной разборкой зависимостей.

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