Supabase Cloud vs. Self-Hosted: Was passt zum Unternehmen?
Timo Wevelsiep•Aktualisiert: 25.08.2026Hinweis zum Inhalt: Versionen, Befehle und Preise können sich ändern. Bitte prüfen Sie kritische Schritte vor dem produktiven Einsatz eigenständig. Dieser Leitfaden ersetzt keine individuelle Beratung.
Sie prüfen einen Cloud-Exit oder möchten den laufenden Betrieb nicht selbst übernehmen? WZ-IT plant die Supabase-Migration ab 3.490 € und betreibt Supabase anschließend auf verwalteter oder kundeneigener Infrastruktur.
Supabase Cloud und Self-Hosted Supabase verwenden denselben Open-Source-Kern, sind aber keine identischen Produkte. In der Cloud betreibt Supabase die Plattform. Beim Self-Hosting werden die Laufzeitkomponenten auf eigener Infrastruktur bereitgestellt und die Betriebsverantwortung wechselt zum Betreiber.
Die Entscheidung sollte deshalb nicht auf „Cloud gegen eigener Server“ reduziert werden. Relevant sind Funktionen, Verfügbarkeit, Datenwege, Wiederherstellung, Personalaufwand und die Verantwortung bei Störungen.
Vergleich auf einen Blick
| Kriterium | Supabase Cloud | Self-Hosted Supabase |
|---|---|---|
| Infrastruktur | Von Supabase betrieben | Eigene, kundenseitige oder verwaltete Infrastruktur |
| Updates | Plattformseitig | Vom Betreiber zu planen und zu testen |
| Backups | Tarifabhängig verwaltet | Eigene Backup- und Restore-Architektur |
| PITR | Tarifabhängiges Add-on | Muss selbst mit PostgreSQL-WAL-Archivierung aufgebaut werden |
| Branching | Plattformfunktion | Nicht automatisch enthalten |
| Monitoring | Plattformmetriken und Logs | Eigene Metriken, Logs, Alarme und Reaktion |
| Projekte | Organisationen und mehrere Projekte | Self-hosted Studio verwaltet einen Stack als ein Projekt |
| Skalierung | Plattform- und Compute-Optionen | Architektur, Ressourcen und Trennung selbst planen |
| Betriebsort | Verfügbare Supabase-Regionen | Frei innerhalb der eigenen Zielarchitektur |
| Verantwortung | Supabase plus Kunde für App und Konfiguration | Betreiber plus Kunde für Plattform und App |
Die offizielle Supabase-Dokumentation nennt für Self-Hosting ausdrücklich fehlende Cloud-Funktionen: Branching, erweiterte Metriken jenseits der Logs, Managed Backups und PITR, Analytics- und Vector-Buckets, ETL sowie die Plattform-Management-API.
Was in beiden Varianten vorhanden ist
Der Self-Hosted-Stack stellt die Kernkomponenten bereit:
- PostgreSQL
- Auth
- Storage
- Realtime
- REST- und GraphQL-APIs
- Functions-Runtime
- Studio
- API-Gateway und Connection Pooling
„Vorhanden“ bedeutet jedoch nicht „gleich betrieben“. Functions laufen beispielsweise self-hosted auf der eigenen Instanz und nicht automatisch global verteilt. Storage benötigt ein definiertes Backend und eine eigene Sicherung. Studio muss abgesichert und administrative Endpunkte dürfen nicht unkontrolliert öffentlich erreichbar sein.
Wann Supabase Cloud die bessere Wahl ist
Die Cloud passt häufig, wenn:
- eine Anwendung noch in einer frühen Phase ist,
- das Team schnell entwickeln möchte,
- wenig interne Plattformkompetenz vorhanden ist,
- Managed Backups und Plattformmetriken gewünscht sind,
- Last und Nutzerzahl zunächst schwer vorhersehbar sind,
- keine Vorgabe für eine eigene Infrastruktur besteht.
Für kleine Projekte kann ein selbstverwalteter Server zwar auf der Rechnung günstiger aussehen. Sobald Bereitschaft, Updates, Backupkontrolle und Wiederherstellung eingerechnet werden, verschiebt sich die Rechnung.
Wann Self-Hosting sinnvoll sein kann
Self-Hosting ist plausibel, wenn:
- ein bestimmter Cloud-, Rechenzentrums- oder On-Premise-Standort erforderlich ist,
- private Netze und interne Systeme direkt angebunden werden müssen,
- die Plattform in eine vorhandene Backup- und Monitoring-Landschaft integriert wird,
- Kapazität und Kosten planbarer dimensioniert werden sollen,
- ein isolierter Betrieb benötigt wird,
- das Unternehmen die technische Betriebsverantwortung selbst oder über einen Dienstleister abbildet.
Der Wunsch nach Kontrolle allein reicht nicht. Entscheidend ist, ob diese Kontrolle organisatorisch ausgeübt wird: Wer bewertet Updates? Wer reagiert auf Alarme? Wie wird Storage wiederhergestellt? Wie lange darf PostgreSQL ausfallen?
Managed Self-Hosting als dritte Option
Zwischen Supabase Cloud und vollständig eigenem Betrieb liegt Managed Self-Hosting. Die Plattform läuft auf einer dedizierten oder kundeneigenen Zielumgebung, während ein Betreiber definierte Aufgaben übernimmt:
- Installation und Härtung
- Monitoring und Alarmierung
- Updates und getestete Deployments
- Datenbank- und Storage-Backups
- Restore-Tests
- Incident-Reaktion nach Service Level
- technische Dokumentation
Damit lassen sich Betriebsort und Infrastruktur kontrollieren, ohne jede Plattformaufgabe im Anwendungsteam zu verankern.
Der Wechsel ist eine Migration, kein Schalter
Beim Umzug aus der Cloud müssen mindestens folgende Ebenen betrachtet werden:
- PostgreSQL-Rollen, Schema und Daten
- Auth-Nutzer, Provider, SMTP, JWT und Redirects
- Storage-Metadaten und tatsächliche Objekte
- Functions, Secrets und Webhooks
- Realtime, Pooling und Domains
- Frontend- und Serverkonfiguration
- Test, Cutover und Rückfall
Die offizielle Restore-Anleitung deckt bewusst nur die Datenbankwiederherstellung ab und weist darauf hin, dass Storage-Objekte und Functions separat behandelt werden müssen.
Entscheidungsmatrix
| Ausgangslage | Sinnvoller Start |
|---|---|
| MVP ohne besondere Infrastrukturvorgaben | Supabase Cloud |
| Produktive App ohne eigenes Plattformteam | Cloud oder Managed Self-Hosting |
| Fester Betriebsort und eigene IT-Verantwortung | Self-Hosted |
| Fester Betriebsort ohne eigenes Betriebsteam | Managed Self-Hosting |
| Cloud-Projekt mit unbekannten Abhängigkeiten | Assessment vor einer Migration |
| Kritische App mit sehr geringer Downtime | Individuelle Migrations- und HA-Architektur |
Die wirtschaftliche und technische Entscheidung sollte jährlich neu geprüft werden. Nutzerzahl, Storage, Egress, Betriebsanforderungen und interne Kapazitäten ändern sich mit der Anwendung.
Quellen
Lieber betreiben lassen?
Sie möchten Supabase nicht selbst betreiben? WZ-IT übernimmt Einrichtung, Betrieb und Wartung - datenschutzorientiert aus Deutschland.
Anfrage
Supabase migrieren, absichern oder betreiben
Wir migrieren Supabase-Projekte und bestehende Backends wie Firebase, Lovable, PostgreSQL, MySQL oder Auth0, bauen die Zielumgebung auf und übernehmen auf Wunsch den laufenden Betrieb.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen
Nein. Die zentralen Laufzeitkomponenten sind verfügbar, aber verwaltete Funktionen wie Branching, Managed Backups und PITR, erweiterte Plattformmetriken und die Management-API sind beim Self-Hosting nicht automatisch enthalten.
Nein. Neben Serverkosten müssen Administration, Monitoring, Backups, Restore-Tests, Updates und Störungsreaktion eingerechnet werden. Für kleine oder frühe Projekte ist die Cloud häufig wirtschaftlicher.
Ja. PostgreSQL, Auth-Daten, Storage, Functions und Anwendungskonfiguration müssen jedoch als getrennte Migrationsbereiche geplant werden. Ein Datenbankdump allein bildet nicht das gesamte Backend ab.
Wenn Kontrolle oder ein bestimmter Betriebsort benötigt werden, das Team aber Updates, Backups, Monitoring und Recovery nicht selbst verantworten möchte.
Mehr zu Supabase
- Was ist Supabase?
- Supabase Cloud vs. Self-Hosted
- Supabase Self-Hosting: Vorteile & Nachteile
- Supabase-Kosten: Cloud vs. Self-Hosted
- Supabase Cloud zu Self-Hosted migrieren
- Supabase-Projekt, Region oder Organisation migrieren
- PostgreSQL zu Supabase migrieren
- AWS RDS und Aurora zu Supabase migrieren
- Heroku Postgres zu Supabase migrieren
- Neon und Vercel Postgres zu Supabase migrieren
- MySQL und MariaDB zu Supabase migrieren
- Microsoft SQL Server und Azure SQL zu Supabase migrieren
- Firebase zu Supabase migrieren
- Lovable Cloud zu Supabase migrieren
- Auth0 zu Supabase Auth migrieren
- Supabase-Migrationscheckliste
- Supabase vollständig sichern
- Supabase Self-Hosted aktualisieren
- Supabase RLS prüfen
- Supabase auf Hetzner betreiben
- Supabase mit Coolify installieren
