Supabase: backend-as-a-service на PostgreSQL, который можно поднять через Docker

Backend для нового проекта — это всегда одна и та же рутина. Авторизация, CRUD-запросы, загрузка файлов, подключение к базе. Каждый раз заново, каждый раз одинаково. Supabase собирает этот набор в одну коробку поверх PostgreSQL — и не просит за это денег, если поднимаете у себя.

107 тысяч звёзд на GitHub, лицензия Apache 2.0, активная разработка с 2019 года. Последний релиз — июль 2026. Можно запустить в облаке за минуту или поднять через Docker на своём сервере. Забрать дамп и уехать — в любой момент.

Это не Firebase. Это PostgreSQL с надстройкой.

Что это и как начать

Backend-as-a-service (BaaS) — подход, при котором серверную часть приложения берёт на себя готовая платформа. Вам не нужно писать API-эндпоинты, настраивать авторизацию, подключать хранилище файлов и управлять вебсокетами. Платформа отдаёт всё это из коробки, вы подключаетесь клиентским SDK и сразу работаете с данными.

Supabase — open-source BaaS, построенный на PostgreSQL. Похож на Firebase, но с принципиальным отличием: underneath — полноценная реляционная база, не NoSQL. У вас есть JOIN-ы, транзакции, миграции, расширения. И дамп, который можно забрать с собой.

Два способа начать:

1. Облако — регистрация на supabase.com, создание проекта, получение URL и API-ключей. Бесплатный тариф: 500 МБ базы, 1 ГБ хранилища, 50 000 активных пользователей.
2. Self-hosted — клонирование репозитория, копирование .env, docker compose up -d. Тот же стек, только на вашем сервере. Пять минут от старта до рабочего дашборда.

Инсайт: Облако и self-hosted — один и тот же код. Не урезанная community-версия и не проприетарная enterprise-версия. Вы можете начать в облаке, а потом безболезненно переехать на свой сервер — API совместимы.

Зачем нужен

Когда хочется начать проект быстро и не писать с нуля то, что написали до вас сто раз. Авторизация, CRUD, загрузка файлов, вебсокеты — это не конкурентное преимущество, это базовая инфраструктура.

Типичные сценарии:

• MVP и прототипы с полноценным бэкендом за пару часов
• Мобильные и веб-приложения, где нужен быстрый auth + база
• Замена Firebase для тех, кому нужна реляционная модель, а не документная
• Локальный backend для дев-окружения без зависимости от облака
• Pet-проекты на бесплатном тарифе

Почему PostgreSQL важен: Firebase хранит данные в формате документов (NoSQL). Вы получаете древовидные структуры без JOIN-ов и транзакций. PostgreSQL даёт нормальную реляционную базу: связи между таблицами, ACID-транзакции (атомарные, непротиворечивые, изолированные, долговечные операции), миграции схемы, расширения. И возможность в любой момент забрать дамп и уехать на свой сервер — без переписывания кода.

Что в коробке

Supabase — не один инструмент, а набор из шести, связанных одной инфраструктурой:

• PostgreSQL — полноценная база без урезанных режимов. Поддерживает расширения: pgvector (векторный поиск для AI-приложений), PostGIS (геоданные), pg\_cron (планировщик задач внутри базы).
• Auth — регистрация по email, magic link (вход по ссылке без пароля), OAuth через Google, GitHub, Apple и ещё десяток провайдеров, OTP (одноразовые коды), SSO для корпоративных клиентов.
• Storage — файловое хранилище, совместимое с S3 API (стандарт протокола объектного хранения Amazon). Права доступа настраиваются через RLS-политики.
• Realtime — подписки на изменения в таблицах через WebSocket (протокол, поддерживающий постоянное двустороннее соединение между клиентом и сервером). Клиент получает обновления в момент, когда данные меняются, без опроса.
• Edge Functions — serverless-функции на Deno (runtime для JavaScript/TypeScript с упором на безопасность). Запускаются ближе к пользователю — меньше задержка.
• Auto-generated API — REST и GraphQL поверх схемы PostgreSQL. Не нужно писать бэкенд: API генерируется автоматически из структуры таблиц.

Клиентские SDK (набор для разработки) есть для JavaScript, TypeScript, Python, Dart/Flutter, Swift, Kotlin. Подключаетесь к базе из любого клиента — от веб-приложения до мобильного.

Два способа запускать

Облако

Регистрируетесь на supabase.com, создаёте проект — получаете URL вида https://xxx.supabase.co, API-ключи и доступ к дашборду. Бесплатный тариф: 500 МБ базы, 1 ГБ хранилища, 50 000 MAU (monthly active users — активных пользователей в месяц). Для прода — Pro от $25/мес.

Self-hosted через Docker

Полностью тот же стек, но на вашем сервере или ноутбуке. Подходит для локальной разработки, закрытых контуров и случаев, когда нужен полный контроль над данными.

Быстрая установка локально

Предполагается, что Docker уже установлен.

Шаг 1. Клонировать репозиторий

git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

Шаг 2. Скопировать env

cp .env.example .env

В .env минимум поменяйте:

• POSTGRES\_PASSWORD — пароль к базе
• JWT\_SECRET — длинная случайная строка, минимум 32 символа. JWT (JSON Web Token) — стандарт для передачи подписанных данных между сторонами; секрет нужен для проверки подписи.
• ANON\_KEY и SERVICE\_ROLE\_KEY — сгенерируйте на странице self-hosting в документации Supabase, там есть online-генератор
• DASHBOARD\_USERNAME / DASHBOARD\_PASSWORD — доступ к Studio (веб-интерфейсу управления)

Шаг 3. Поднять стек

docker compose pull
docker compose up -d

Первый запуск — минуту-две, качаются образы. Дальше — секунды.

Шаг 4. Открыть дашборд

• Studio (UI): http://localhost:8000
• API: http://localhost:8000 (префиксы /rest/v1, /auth/v1, /storage/v1)
• Postgres: localhost:5432, пользователь postgres, пароль из .env

Шаг 5. Остановить / сбросить

# Остановить
docker compose down

# Снести вместе с данными
docker compose down -v

Подключение из приложения

JavaScript / TypeScript

npm install @supabase/supabase-js

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

const supabase = createClient(
  'http://localhost:8000',
  'YOUR_ANON_KEY'
)

// Запрос к таблице
const { data, error } = await supabase
  .from('posts')
  .select('*')
  .order('created_at', { ascending: false })

// Авторизация
await supabase.auth.signInWithPassword({
  email: 'user@example.com',
  password: 'secret',
})

// Realtime подписка
supabase
  .channel('posts')
  .on('postgres_changes', { event: '*', schema: 'public', table: 'posts' }, (payload) => {
    console.log('Change:', payload)
  })
  .subscribe()

CLI для миграций

npm install -g supabase

# Инициализация проекта
supabase init

# Новая миграция
supabase migration new create_posts_table

# Применить к локальной БД
supabase db push

Row Level Security — главная фишка

RLS (Row Level Security) — механизм PostgreSQL, который ограничивает доступ к строкам таблицы на уровне базы данных. Вместо того чтобы проверять права в бэкенд-коде, вы пишете SQL-политики — и база сама решает, кто какие строки видит, создаёт или меняет.

Supabase завязан на RLS. Клиент ходит напрямую в базу, политики защищают данные. Бэкенд для большинства CRUD-сценариев не нужен вообще.

-- Включить RLS
alter table posts enable row level security;

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

-- Создавать может только авторизованный
create policy "Authenticated can insert"
  on posts for insert
  with check (auth.role() = 'authenticated');

auth.uid() — функция Supabase, которая возвращает ID текущего пользователя из JWT-токена. auth.role() — его роль (authenticated или anon). Политики применяются автоматически к каждому запросу через Auto-generated API.

Важно: RLS выключен по умолчанию. Если вы создаёте таблицу и не включаете RLS, клиент с anon-ключом видит все строки. Это не баг — это явное решение разработчика, и его нужно принимать осознанно.

Лицензия и цены

Тариф	Цена	База	Хранилище	MAU	Особенности
Self-hosted	Бесплатно (Apache 2.0)	Без ограничений	Без ограничений	Без ограничений	Полный стек на вашем сервере
Free (облако)	$0	500 МБ	1 ГБ	50 000	Проект засыпает через 7 дней простоя. Лимит — 2 активных проекта
Pro	$25/мес	8 ГБ	100 ГБ	100 000	Без сна. $10/мес в compute-кредитах. Ежедневные бэкапы (7 дней). Email-поддержка
Team	$599/мес	По потреблению	По потреблению	По потреблению	SSO, SOC 2, ISO 27001, приоритетная поддержка, бэкапы 14 дней
Enterprise	По договору	—	—	—	Выделенный менеджер, SLA, BYO Cloud, 24/7 поддержка

Дополнительные проекты на Pro — от $10/мес каждый. Compute-инстансы: от Micro ($10, 2-core ARM, 1 ГБ RAM) до 16XL ($3,730, 64-core ARM, 256 ГБ RAM). Pro включает compute-кредит на один Micro-инстанс.

Совет: Для знакомства — Free в облаке. Для прода с предсказуемой нагрузкой — Pro. Для закрытых контуров и полного контроля — self-hosted через Docker. Переезд между облаком и self-hosted не требует переписывания кода: API совместимы.

Ограничения

Ограничения

NoSQL как родная модель не поддерживается — PostgreSQL хранит данные в таблицах.

JSONB (формат хранения JSON в Postgres) помогает работать с документами, но это не MongoDB. Если архитектура построена на документах без связей — Firebase или Mongo подойдут лучше.

Комплаенс на бесплатном тарифе отсутствует — SOC 2, ISO 27001, HIPAA доступны начиная с Team-плана ($599/мес).

Для regulated industries (медицина, финансы) Free не подойдёт.

Edge Functions не заменяют бэкенд — Deno-функции годятся для лёгкой логики: вебхуки, трансформация данных, валидация.

Для сложной бизнес-логики лучше отдельный сервис — Hono, Fastify, Go-сервер. Edge Functions ограничены по времени выполнения и ресурсам.

Realtime не рассчитан на миллионы подключений

— WebSocket-подписки работают надёжно для типичных приложений, но для чата на миллионы одновременных соединений нужны специализированные решения.

Антипаттерны

Антипаттерны

Включить RLS, но не написать политики — таблица с включённым RLS и без политик блокирует все запросы от anon-роли.

Пользователи не видят ни одной строки. Решение: либо пишите политики, либо явно отключайте RLS для публичных таблиц.

Использовать service_role key на клиенте — SERVICE\_ROLE\_KEY обходит RLS полностью.

Если этот ключ попадёт в клиентский код, любой пользователь получит полный доступ к базе. Только для серверных вызовов.

Игнорировать .env перед коммитом — .env содержит пароли, JWT-секрет и ключи.

Если не добавить .env в .gitignore, секреты уйдут в репозиторий. Шаблон .env.example уже включает пустые значения — не заменяйте его.

Не делать бэкапы на self-hosted — docker compose down -v удаляет данные.

Без настроенного pg\_dump или томов с бэкапом потеря данных необратима. На Pro в облаке бэкапы включены, на self-hosted — ваша ответственность.

Чеклист

Чеклист

JWT\_SECRET в .env

— минимум 32 символа, сгенерирован случайно, не скопирован из примера

SERVICE\_ROLE\_KEY не используется в клиентском коде

— только в серверных вызовах

.env добавлен в .gitignore

— секреты не уйдут в репозиторий

RLS включён на таблицах с пользовательскими данными

— и политики написаны

ANON\_KEY используется только на клиенте

— прав достаточно для публичных операций

Docker-тома настроены для персистентности данных

— docker compose down без -v не должен терять данные

Бесплатный проект в облаке проверен на простой

— через 7 дней неактивности он засыпает

Ссылки

Ссылки

• Сайт: Supabase
• Документация: Supabase Docs
• GitHub: supabase/supabase
• Цены: Supabase Pricing

По теме

По теме

• База знаний: Strapi: open-source Headless CMS, которую вы разворачиваете на своём сервере
• База знаний: Backend за кнопкой: что происходит между кликом и результатом
• База знаний: API как язык между сервисами: что это, зачем нужно и как читать ответы
• База знаний: Webhook: как системы получают сигналы в момент события
• База знаний: Redis: in-memory база для кэша, стримов и контекста агентов