Self-Hosted Supabase Doesn't Break Because Postgres Is Hard

Описание и применение

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

Задача

Teams running self-hosted Supabase in production face coordination issues among the ten independently versioned services (auth, realtime, storage, etc.), leading to version drift, silent data loss during deploys, and proxy-related errors, rather than database problems.

Результат

By aligning local and production service versions, managing realtime deploys, and addressing proxy compatibility, teams reduced production failures caused by coordination problems.

Рабочий процесс

• 1. Identify service versions running in production.
• 2. Pin local development to those same versions to avoid version drift.
• 3. Schedule realtime service deploys during low-traffic periods and manually verify subscription counts before and after.
• 4. Configure reverse proxies to match header expectations for S3-compatible storage.
• 5. Document pinned versions and deployment windows for onboarding and maintenance.

Доказательства

Nobody complained about Postgres. Every team described it as boring and working.

Источник

The pain is the surrounding services: auth, realtime, storage, proxy, meta, and the rest

Источник

The workaround everyone lands on is pinning local development to the same service versions as production.

Источник