Supabase — это краеугольный камень многих low-code и no-code платформ (Lovable — хороший тому пример) и он получил широкое распространение с приходом эпохи vibe-coding. Не просто так - им (супер)легко пользоваться как AI-кодинг агентам, так и углеродным формам жизни.
Идея здесь очень простая: Postgres (open source) + PostgREST (тоже open source) + Auth (GoTrue - вы угадали - open source) + Edge Functions API (Deno, open source) + Storage API для хранения бинарных данных.
Если коротко - это BaaS, или backend as a service, или, другими словами, если вам нужен бекенд, но вы не хотите заниматься им в каком-либо виде - Supabase уже здесь. Он берет на себя деплой, масштабирование, аутентификацию и управление базой данных, позволяя вам сосредоточиться на продукте.
В некотором смысле он убирает необходимость иметь отдельного девопс / админа / администратора БД. Для стартапа преимущества очевидны: свободного времени и рук почти никогда не бывает, поэтому можно сэкономить массу времени, переложив управление бэкендом на BaaS. И, если честно, кому вообще хочется этим заниматься? Гораздо приятнее потратить это время более продуктивно - например, на думскроллинг в Twitter.
Supabase это open source, что убирает пресловутую проблему vendor lock-in, которая существует у похожих, но более старых решений вроде Firebase. Поскольку по сути это просто Postgres с набором open-source свистелок, вы всегда можете уехать с Supabase или развернуть его самостоятельно.
Таким образом, преимущества для стартапа или небольшого POC-проекта очевидны. Но что насчет более крупных, корпоративного уровня проектов? Может ли Supabase справиться с ними?
Ответ - скорее всего, нет.
И это не вина Supabase - это осознанное архитектурное решение. Как видно, центральной частью Supabase является Postgres, так что если вы не хотите использовать Postgres - а многие ентерпрайз решения действительно не хотят (не могут) - вы исключаетесь из уравнения. Но даже если бы это не было проблммой, сама концепция Supabase строится вокруг бэкенда, ориентированного на работу с реляционными данными, большим количеством простых CRUD-операций и (в идеале) row-level security (проще говоря, безопасностью на уровне доступа к данным), а не на сложной ролевой модели.
Сколько enterprise-систем подходят под это описание? Думаю, не так уж много. Если у вашей системы сложная бизнес-логика и множество интеграций с внешними системами, вам потребуются продвинутые архитектурные паттерны вроде микросервисов, ивентов, кастомных очередей/стримов, long-running задач и т. д. Supabase здесь вам не поможет — скорее наоборот, усложнит жизнь, потому что он для этого не предназначен. Технически, конечно, можно вынести всё это в отдельный сервис(ы), а Supabase использовать для базовой логики — но в чем тогда смысл, если в таком случае это всё равно не будет составлять основную часть усилий по проекту?
В остальном Supabase - отличный инструмент для своей задачи. Open source, достаточно гибкий, чтобы довести множество стартап-идей очень далеко, прежде чем он упрется в свои ограничения.
Vercel
Теперь посмотрим на Vercel. Vercel - это FaaS, или frontend as a service (хотя сейчас у них есть и некоторые бекенд-возможности). Как можно догадаться из названия, он закрывает другую сторону уравнения, поэтому его часто используют вместе с Supabase.
Vercel - это облачная платформа, ориентированная на фронтенд: быстрый и простой деплой, CI/CD, CDN, а также очень быстрая доставка и масштабирование с (почти) нулевым обслуживанием, благодаря serverless-функциям, специально оптимизированным под Next.js.
Собственно, Next.js был создан самой Vercel, так что, как несложно догадаться, их платформа максимально оптимизирована под него, хотя при желании можно использовать и большинство популярных JS-фреймворков. Платформа автоматически определяет используемый фреймворк и настраивает корректные параметры сборки и вывода.
Vercel не является open source, хотя многие его компоненты, такие как Next.js, - да. Поэтому он не похож на Supabase, и проблема vendor lock-in здесь существует и должна учитываться. От многих возможностей Vercel будет сложно отказаться при миграции, если вы активно их используете - например, Edge Functions / Middleware работают на проприетарном, нестандартном Edge Runtime.
Vercel во многом похож на Supabase, хотя и более ограничен. Он отлично подходит для стартапов и Node.js-проектов средней сложности, которым требуется очень высокая производительность фронтенда. Он плохо подходит для не-Node.js бэкендов и не рассчитан на real-time приложения (например, с WebSockets), поскольку не поддерживает long-running процессы. Вся его суть - это скорость разработки и скорость работы фронтенд-приложения. Vercel не подходит для сложных веб-приложений с большим количеством интеграций, где требуется тонкая настройка бэкенда. И, кроме того, при большом трафике он становится довольно дорогим.
Так что если вы стартап, который поднял много денег и они жгут вам руки (пока инвесторы жгут вам задницу) - использование связки Vercel + Supabase имеет смысл. Но ни то, ни другое не заменяет хорошую архитектуру системы.
Railway
Railway - это PaaS (platform as a service), то есть платформа, которая предоставляет инфраструктуру/рантайм для запуска вашего бэкенда, но не сам бэкенд (в отличие от Supabase). Это не "черный ящик", и он отлично располагается между такими платформами, как Vercel, давая вам полный контроль над архитектурой бэкенда. Если вы пользовались Heroku - это примерно то же самое, но более современное.
Основная идея в том, что вы пушите код в репозиторий, а Railway берет на себя всё остальное, и в итоге вы получаете production-ready сервис. Вы можете использовать докер файлы, если вам нужен полный контроль, а если нет - платформа автоматически определит ваш стек.
В отличие от Vercel, Railway поддерживает долгие процессы (хотя за это придется платить) и фоновые воркеры. По сути, это более простая альтернатива managed Kubernetes, которая позволяет сосредоточиться на разработке, а не на инфраструктуре и девопс, но при этом сохранить гибкость полной настройки, если вам это нужно.
Фактически, Railway можно использовать вплоть до того момента, когда вам действительно понадобится Kubernetes - а до этого этапа большинство проектов вообще никогда не доходит.
Ценообразование здесь гораздо более предсказуемо по сравнению с такими сервисами, как Vercel. По сути, вы платите за потребление, и цены выглядят разумно. Конечно, варианты вроде Hetzner с самостоятельным управлением инфраструктурой дешевле с точки зрения денег, но если учесть затраты времени - картина может выглядеть совсем иначе, так что считать нужно самостоятельно.
Всем добра!
Я из Рафт. Мой телеграм-канал.
Пишите ваши вопросы в комментариях.