Какие ограничения self-host?

Self-host Supabase даёт контроль, но есть ограничения и ответственность, которые важно учитывать с цифрами и сроками: Обновления: ручная или CI-автоматизация, ожидайте 10–20 минут простоя на сервис при неполной zero-downtime миграции; на Kubernetes можно добиваться 0 downtime, но это требует подготовки образов и readiness checks. Поддержка: официальной SLA от Supabase Inc. на open-source нет — коммерческая поддержка доступна по контракту, но цены в 2026 стартуют от $2,000/месяц для enterprise, если вам нужна гарантированная помощь. Масштабирование: для проектов >1M MAU понадобится распределённая архитектура с read replicas PostgreSQL и шардинг — этого нет «из коробки» в Supabase; от вас требуется ручной шардинг или использование Citus/pg_shard. Сложность: вы управляете секретами, бэкапами, обновлениями и безопасностью — это минимум 0.5 FTE DevOps на проект при нагрузке от 100k MAU. Практическое замечание по стоимости: на 2026 год полный self-host стека на выделенной ноде 8 vCPU/32...

Что с обновлениями?

Обновления self-host требуют тестового стенда и планирования. Я использую стратегию "staging-first": в 2026 стандартный цикл — weekly minor updates и monthly major updates. В production применяю только те патчи, которые прошли smoke-тесты на staging за 72 часа. Процесс обновления компонентов выглядит так: Собираем changelog компонентов (realtime, gotrue, storage-api, postgrest) и проверяем breaking changes. Обновляем Docker images в CI и тестируем миграции данных на staging (занимает 1–3 часа в зависимости от объёма базы). Делать бэкап базы и конфигов до обновления (полная копия + WAL). Проверка бэкапа занимает 30–90 минут. Применяем обновление в production в maintenance window 02:00–04:00 по UTC; ожидаем окно 10–20 минут для рестарта сервисов, но для safety резервируем 60 минут в случае отката. Если нужно без downtime, делаем Kubernetes rolling update с readinessProbe и preStop hook. В Compose можно использовать blue/green deploy: запускаем новые сервисы на другом порту,...

Как перенести существующую Firebase-схему на Supabase self hosted?

Миграция предполагает перенос данных и логики: сначала экспортируйте данные из Firebase (JSON или CSV), затем преобразуйте документы в реляционные таблицы с ключами и индексами. Для auth — сопоставьте Firebase UID с auth.users в Supabase, импорт через CSV + SQL. Часто потребуется написать скрипт на Node.js/Python, который читает коллекции, нормализует вложенные объекты и делает batch insert в PostgreSQL по 1000 записей за транзакцию. Планируйте тестовый перенос и проверку referential integrity; на проектах до 200k записей миграция занимает от нескольких часов до суток с учётом индексации.

Что делать при массовом росте WebSocket-подключений?

Если ожидается резкий рост — горизонтально масштабируйте Realtime: добавьте дополнительные поды/контейнеры и отдельные replication slots. Также увеличьте max_replication_slots и max_wal_senders в PostgreSQL. Балансируйте WS через Nginx или HAProxy с sticky-сессиями при необходимости. Для проектов 1k→10k одновременных подключений рекомендуются как минимум 4–8 подов realtime и выделенная сеть 1–10 Gbps; тестируйте нагрузку локально с инструментами вроде k6 или Artillery.

Где хранить секреты и как их ротировать?

Секреты храните в HashiCorp Vault, AWS KMS, GCP KMS или в managed секретном хранилище провайдера. Ротация: сервисные ключи — каждые 90 дней, JWT секреты — каждые 30 дней. Автоматизируйте обновление через CI/CD: деплой нового секрета в Vault, обновление env в Service Discovery и rolling restart сервисов. Убедитесь, что старые ключи принимают токены ещё 24 часа для graceful session expiry.

Сколько стоит self-host по сравнению с managed Supabase?

Стоимость зависит от профиля: для SMB с одной нодой 8 vCPU/32 GB RAM/2 TB NVMe — ~700–1200 USD/мес; добавьте расходы на бэкап-объём и CDN — ещё 100–300 USD. Managed Supabase для схожих ресурсов может стоить 1,000–3,000 USD/мес, но включает SLA и поддержку. Если у вас есть DevOps 0.5–1 FTE, self-host часто выгоднее при высоких SLA требований к контролю данных и соответствию регуляциям.

Почему некоторые сервисы периодически теряют соединение с базой?

Чаще всего причина — исчерпание connection pool или недоходящие репликационные слоты при росте WAL. Проверьте max_connections и настройки connection pooling (pgBouncer рекомендуемый). Для Supabase рекомендую ставить pgBouncer между приложениями и Postgres: pool_mode = session или transaction, pool_size = 100–500 в зависимости от нагрузки. Также мониторьте long-running queries и применяйте индексы. Ресурсы и продолжение: для практических гайдов по Docker и безопасности смотрите Как настроить Docker и Руководство по безопасности бэкенда на ktohto.ru.

Supabase self-hosted: Firebase killer 2026

Supabase self-hosted: Firebase killer 2026 | KtoHto

version: "3.8"
services:
  db:
    image: postgres:15.4
    environment:
      POSTGRES_PASSWORD: "postgres_password_here"
      POSTGRES_USER: "supabase_admin"
      POSTGRES_DB: "postgres"
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - supanet

  realtime:
    image: supabase/realtime:1.5.0
    environment:
      DB_HOST: db
      DB_PORT: "5432"
      DB_USER: supabase_admin
      DB_PASSWORD: "postgres_password_here"
      REPLICATION_SLOT: "supabase_realtime"
    depends_on:
      - db
    networks:
      - supanet
    deploy:
      resources:
        limits:
          cpus: '4'
          memory: 8G

  auth:
    image: supabase/gotrue:1.28.0
    environment:
      GOTRUE_DB_DRIVER: "postgres"
      GOTRUE_DB_DATABASE_URL: "postgres://supabase_admin:postgres_password_here@db:5432/postgres"
      SITE_URL: "https://auth.example.com"
    depends_on:
      - db
    networks:
      - supanet

  storage:
    image: supabase/storage-api:0.17.0
    environment:
      POSTGREST_URL: "http://postgrest:3000"
      ANON_KEY: "anon_key_value"
    depends_on:
      - db
    volumes:
      - storage-data:/var/lib/storage
    networks:
      - supanet

volumes:
  db-data:
  storage-data:

networks:
  supanet:

server {
  listen 443 ssl http2;
  server_name realtime.example.com;
  ssl_certificate /etc/ssl/certs/fullchain.pem;
  ssl_certificate_key /etc/ssl/private/privkey.pem;

  location / {
    proxy_pass http://127.0.0.1:4000/; # порт контейнера realtime
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 86400; # держим долго долгоживущие WS
  }
}

GOTRUE_SITE_URL=https://app.example.com
GOTRUE_JWT_SECRET=your_jwt_secret_32_chars_min
GOTRUE_JWT_EXPIRES_IN=3600 # секунды
GOTRUE_JWT_REFRESH_EXPIRES_IN=2592000 # 30 дней
SMTP_HOST=smtp.example.com
SMTP_PORT=587
SMTP_USER=smtp_user
SMTP_PASS=smtp_pass

CREATE TABLE public.messages (
  id uuid DEFAULT gen_random_uuid() PRIMARY KEY,
  user_id uuid REFERENCES auth.users(id) NOT NULL,
  body text NOT NULL,
  created_at timestamptz DEFAULT now()
);

ALTER TABLE public.messages ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Allow owners" ON public.messages
  FOR ALL
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- Добавим политику для админов
CREATE POLICY "Allow admins" ON public.messages
  FOR ALL
  USING (EXISTS (SELECT 1 FROM public.user_roles ur WHERE ur.user_id = auth.uid() AND ur.role = 'admin'));

CREATE INDEX idx_messages_user_created ON public.messages (user_id, created_at DESC);

MINIO_ENDPOINT=minio:9000
MINIO_REGION=us-east-1
MINIO_ACCESS_KEY=minio_access
MINIO_SECRET_KEY=minio_secret
STORAGE_BACKEND=s3
STORAGE_BUCKET=uploads

mc alias set myminio http://minio:9000 minio_access minio_secret
mc mb myminio/uploads --region us-east-1
mc policy set public myminio/uploads

wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = '2GB'
max_connections = 1000
shared_buffers = '16GB'

SELECT pg_notify('realtime:public:messages', json_build_object('type', 'INSERT', 'record', row_to_json(NEW))::text);

# cron.daily backup
pg_dump -h localhost -U supabase_admin -Fc -f /backups/pg_dump_$(date +%F).dump postgres
# WAL archiving в postgresql.conf
archive_mode = on
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'

Supabase self-hosted: Firebase killer 2026

Комментарии (0)

Что умеет Supabase

Шаг 1: Docker Compose

Шаг 2: auth и RLS

Шаг 3: storage

Шаг 4: Realtime

Шаг 5: мониторинг и бэкапы