Supabase: когда Firebase вырос и надел костюм PostgreSQL

Немного контекста

Осень 2020 года. Firebase доминирует в нише BaaS уже лет пять. Каждый второй мобильный стартап строит на нём бэкенд. Но разработчики начинают ворчать. NoSQL-ограничения Firestore бесят. Цены растут. Vendor lock-in пугает. Хочется SQL, хочется нормальных отношений между таблицами, хочется миграций, хочется открытого кода.

И тут появляется Supabase. «Open source Firebase alternative», — гласит заголовок на сайте. Звучит как мечта. Но мы уже обжигались на «убийцах» всего и вся. Я решил подождать год. Потом ещё год. А в 2023 сел и мигрировал три проекта. И знаете что? Мечта оказалась не такой уж иллюзией.

Архитектура: что внутри

Supabase не изобретает базу данных. Он берёт лучшее, что есть в open source, и упаковывает в единый сервис:

Ключевой момент: под капотом настоящий PostgreSQL. Не эмуляция SQL поверх документов. Не «SQL-подобный» язык запросов. Самый обычный Postgres со всеми его возможностями: индексы всех видов, оконные функции, транзакции, CTE, представления, триггеры, расширения. И прямой доступ через любой PostgreSQL-клиент.

Это означает две вещи. Хорошую: вы можете делать JOIN и писать сложные аналитические запросы, не обходя ограничения Firestore. И сложную: с большой силой приходит большая ответственность — спроектировать схему базы нужно грамотно.

Клиентский SDK: JavaScript съедает мир

Supabase-js — это главный клиентский SDK. Установка одной командой, инициализация тремя строчками:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://xyz.supabase.co',
  'anon-key'
)

Дальше — магия PostgREST. REST API генерируется автоматически из вашей схемы данных. Вы создали таблицу posts — у вас автоматически появились эндпоинты для CRUD-операций. Со сложной фильтрацией, сортировкой и пагинацией:

const { data, error } = await supabase
  .from('posts')
  .select('title, author:profiles(name, avatar)')
  .eq('published', true)
  .order('created_at', { ascending: false })
  .range(0, 9)

Одним запросом: выборка полей, JOIN с профилем автора (включая имя и аватар), фильтр, сортировка, пагинация. Без написания единой строчки бэкенд-кода.

Real-time: подписки без боли

Real-time в Supabase реализован через Postgres LISTEN/NOTIFY и WebSocket. Вы подписываетесь на изменения таблицы и получаете их мгновенно:

supabase
  .channel('room-1')
  .on('postgres_changes',
    { event: '*', schema: 'public', table: 'messages' },
    (payload) => console.log(payload.new)
  )
  .subscribe()

Это работает для INSERT, UPDATE, DELETE. Можно фильтровать по конкретным колонкам. Задержка — единицы миллисекунд. Для чатов, дашбордов, коллаборативных приложений — золото.

Отдельно упомяну Broadcast и Presence — более высокоуровневые абстракции поверх real-time. Broadcast позволяет отправлять сообщения между клиентами в одном «канале» (идеально для показа курсора при совместном редактировании). Presence отслеживает, кто онлайн. Всё это из коробки, без Redis и дополнительной инфраструктуры.

Аутентификация и Row Level Security

Supabase Auth базируется на GoTrue — JWT-сервере с поддержкой email/пароль, магических ссылок, OAuth (40+ провайдеров), телефона и SAML.

Настоящая сила проявляется в связке с Row Level Security PostgreSQL. Вы пишете политики на SQL, и они автоматически применяются ко всем запросам через клиентский SDK:

create policy "Пользователь видит только свои посты"
on posts for select
using (auth.uid() = user_id);

Три строчки SQL — и каждый пользователь видит только свои записи. Никакого middleware, никакой ручной проверки прав. Политики распространяются на REST API, real-time и прямой доступ к базе.

Хранилище файлов

S3-совместимое хранилище с resizing-ом и кэшированием через CDN. Загружаете файл через SDK, получаете публичный URL, навешиваете те же RLS-политики на бакеты. Изображения можно трансформировать на лету: ?width=200&height=200&resize=cover.

Self-hosting vs Cloud

У Supabase есть два режима работы:

• Cloud — их хостинг на AWS. Бесплатный тир включает 500 MB базы и 2 проекта. Pro — от $25/мес. Хорошо для старта.
• Self-hosting — через Docker Compose, Kubernetes или их CLI. Полный контроль, ваши серверы, ваш регион. Бесплатно, кроме стоимости серверов.

Самостоятельное развёртывание — не фикция. Я поднимал Supabase на своих серверах через docker compose up. Работает стабильно. Но обновления нужно отслеживать и применять самому — миграции схемы, новые фичи, патчи безопасности.

Где Supabase пока слаб

Критика должна быть честной. Вот что меня беспокоило и беспокоит:

• Edge Functions на Deno. Они медленнее стартуют (cold start), чем Cloudflare Workers. Экосистема Deno меньше, некоторые npm-пакеты несовместимы. Для тяжёлых функций лучше вынести на отдельный сервер.
• Нет нативного гео-запроса. PostGIS установлен, но SDK не предоставляет удобных методов для «найти ближайшие 10 точек». Пишите сырой SQL.
• Full-text search. Встроенный текстовый поиск PostgreSQL уступает Elasticsearch или Meilisearch. Для сложного поиска придётся интегрировать внешний сервис.
• Observability. Логи функций и запросов к базе есть, но метрики и алерты пока слабые. Придётся подключать внешние инструменты.
• Миграции. Supabase CLI управляет миграциями через DDL-файлы. Работает, но менее зрелый, чем, скажем, Prisma Migrate или Flyway. Нужно аккуратно обрабатывать конфликты.

Стоит ли мигрировать с Firebase

Короткий ответ: если вы упёрлись в ограничения Firestore — да.

Развёрнутый: миграция с Firebase на Supabase — это нетривиально. Вы переписываете запросы, перепроектируете схему (из документов в таблицы), переносите аутентификацию, заново настраиваете правила доступа. Это занимает дни или недели.

Но результат того стоит. Запросы, которые в Firestore требовали трёх чтений и клиентской сборки, в Supabase делаются одним SQL с JOIN. Производительность на порядок выше. Цена ниже. И, что важнее психологически, вам больше не нужно бояться, что Firebase поднимет цены или изменит модель — потому что код базы у вас в руках.

Вердикт

Supabase — редкий случай, когда open-source альтернатива не просто «догоняет» коммерческий продукт, а превосходит его по ключевым параметрам. PostgreSQL как основа — это стратегически правильное решение, которое даёт огромный запас прочности и возможностей.

Да, продукт ещё не зрелый во всех аспектах. Да, есть шероховатости в Edge Functions и мониторинге. Но команда движется быстро, каждый месяц выходят значимые обновления, а сообщество растёт бешеными темпами.

Для нового проекта в 2026 году я бы выбирал Supabase как BaaS по умолчанию. Firebase — только если нужна глубокая интеграция с экосистемой Google Cloud. Всё остальное — Supabase.

supabase.com