Supabase Self-Hosting: Vorteile, Nachteile und Eignung

Sie benötigen die Kontrolle einer eigenen Umgebung, möchten Supabase aber nicht intern betreiben? WZ-IT übernimmt Managed Supabase auf eigener, kundenseitiger oder On-Premise-Infrastruktur.

Supabase Self-Hosting lohnt sich nicht allein deshalb, weil Docker Compose gestartet werden kann. Der eigentliche Unterschied zur Cloud liegt in der Betriebsverantwortung. Wer selbst hostet, gewinnt Kontrolle über Infrastruktur und Datenwege, übernimmt aber auch Updates, Backups, Monitoring, Skalierung und Wiederherstellung.

Die wichtigsten Vorteile

Kontrolle über Betriebsort und Netzwerk

Die Plattform kann in einer europäischen Cloud, auf dedizierter Hardware, im eigenen Rechenzentrum oder in einer isolierten Umgebung laufen. Private Netze, VPN, interne APIs und Datenbanken lassen sich ohne öffentliche Umwege anbinden.

Eigene Ressourcen und planbares Sizing

CPU, RAM, Storage und Netzwerk werden passend zum tatsächlichen Lastprofil ausgewählt. PostgreSQL, Storage oder Functions können bei Bedarf getrennt dimensioniert werden. Das ist besonders interessant, wenn eine vorhandene Infrastruktur und ein etabliertes Plattformteam genutzt werden.

Integration in bestehende Betriebsprozesse

Self-Hosted Supabase kann an zentrale Systeme angeschlossen werden:

• Monitoring und Logmanagement
• Secrets Management
• SMTP und Identitätsprovider
• Objekt- und Offsite-Storage
• Backup- und Recovery-Prozesse
• CI/CD und Konfigurationsverwaltung
• private Zugänge und Standortvernetzung

Technische Portabilität

PostgreSQL ist ein etablierter Standard. Datenmodell, SQL-Funktionen und viele Extensions bleiben auch außerhalb von Supabase nutzbar. Das reduziert die Abhängigkeit auf Datenbankebene, beseitigt aber nicht automatisch alle Abhängigkeiten von Auth, Storage, Realtime oder der Data API.

Die wichtigsten Nachteile

Ein Stack aus mehreren Diensten

Supabase besteht nicht nur aus PostgreSQL. Zum Self-Hosted-Stack gehören unter anderem Auth, Realtime, Storage, Studio, Functions, Pooling, Gateway und Logging. Versionskompatibilität und Konfiguration dieser Dienste müssen gemeinsam gepflegt werden.

Keine Managed Backups und kein PITR ab Werk

Die Self-Hosting-Dokumentation nennt Managed Backups und Point-in-Time Recovery ausdrücklich als nicht enthalten. PostgreSQL-Dumps, physische Sicherungen oder WAL-Archivierung müssen selbst aufgebaut werden. Storage-Dateien benötigen zusätzlich einen eigenen Sicherungsweg.

Updates sind Betriebsprojekte

Supabase stellt inzwischen ein update.sh mit Versionsverfolgung und Drei-Wege-Merge bereit. Das Skript sichert jedoch keine PostgreSQL- oder Storage-Daten. Alte oder stark angepasste Installationen können manuelle Konfliktauflösung und gesonderte PostgreSQL-Upgrades erfordern. Details beschreibt die offizielle Update-Anleitung.

Cloud-Funktionen fehlen oder unterscheiden sich

Beim Self-Hosting stehen unter anderem Branching, erweiterte Plattformmetriken, Managed Backups/PITR, Analytics- und Vector-Buckets, ETL und die Plattform-Management-API nicht automatisch zur Verfügung. Functions laufen lokal auf der eigenen Runtime und sind nicht automatisch global verteilt.

Die Verfügbarkeit liegt beim Betreiber

Ein einzelner Docker-Host ist ein Single Point of Failure. Hochverfügbarkeit für PostgreSQL, Storage, Gateway und weitere Dienste ist wesentlich komplexer als eine zweite VM. Vor dem Aufbau müssen RTO, RPO, Last und akzeptierte Ausfallzeit geklärt werden.

Welche Aufgaben dauerhaft anfallen

Wann Self-Hosting passt

Self-Hosting ist häufig geeignet, wenn mindestens mehrere dieser Punkte erfüllt sind:

• Es gibt eine konkrete Vorgabe für Betriebsort oder Netzisolierung.
• Private Systeme und Datenwege sollen direkt angebunden werden.
• Ein Plattformteam oder Managed-Service-Partner ist vorhanden.
• Backup, Monitoring und Incident-Prozesse existieren bereits.
• Last und Kapazität sind ausreichend bekannt.
• Die fehlenden Cloud-Funktionen wurden bewertet.
• Betriebskosten werden als Gesamtaufwand betrachtet.

Wann die Cloud meist sinnvoller bleibt

Supabase Cloud ist oft die bessere Wahl, wenn:

• das Produkt noch keinen stabilen Nutzungsumfang hat,
• ein kleines Entwicklungsteam keine Plattformbereitschaft leisten kann,
• Cloud-Branching und verwaltete Plattformfunktionen wichtig sind,
• nur geringe Infrastrukturkosten gespart würden,
• keine besondere Anforderung an den Betriebsort besteht,
• Recovery und Updates intern nicht zuverlässig abgebildet werden können.

Self-Hosting sollte ein Betriebsmodell lösen und nicht nur eine monatliche Cloud-Rechnung vermeiden.

Managed Self-Hosting reduziert nicht jede Verantwortung

Auch bei einem Dienstleister bleiben Entscheidungen beim Unternehmen: Welche Daten dürfen wohin? Welche Ausfallzeit ist akzeptabel? Welche Auth-Provider werden verwendet? Wer gibt Anwendungsänderungen frei? Ein Managed Service übernimmt technische Aufgaben innerhalb eines bestätigten Scopes, nicht die fachliche Verantwortung für die Anwendung.

Vor einer Migration sollte deshalb ein Assessment die genutzten Cloud-Funktionen, Datenmengen, Authentifizierung, Storage, Functions und Betriebsziele erfassen. Daraus entsteht entweder ein belastbares Self-Hosting-Konzept oder die begründete Entscheidung, zunächst in der Cloud zu bleiben.

Quellen

• Supabase: Self-Hosting
• Supabase: Docker Self-Hosting
• Supabase: Self-Hosted Deployment aktualisieren
• Supabase: Self-Hosted Functions