Supabase oder reines PostgreSQL auf deinem eigenen Server

Das selbstgehostete Docker-Setup von Supabase, Release v0.8.3 vom 16. Oktober 2026, startet 11 Container. Einer davon ist PostgreSQL 17. Die anderen zehn sind ein Gateway, die Anmeldung, eine REST-API, Dateispeicher, Bildskalierung, Live-Updates, Serverfunktionen, ein Connection Pooler, eine Admin-API für die Datenbank und das Studio-Dashboard. Auf einem x86-Server kommen die 11 Images auf etwa 2,15 GB Download – unsere Summe der x86-Größen auf Docker Hub für die Image-Tags in der Compose-Datei. Das offizielle PostgreSQL-17-Image ist etwa 161 MB groß.

Die API-Dokumentation von Supabase beschreibt zwei Nutzungsweisen. Du kannst die APIs so aufrufen: directly from the browser (two-tier architecture), or as a complement to your own API server (three-tier architecture). Wenn eine Browser- oder Smartphone-App mit deiner Datenbank spricht, sind diese zehn Dienste das Backend, das du sonst selbst schreiben würdest. Sitzt ein eigener Server dazwischen, ist PostgreSQL der Teil, den deine App nutzt.

Was Supabase zu PostgreSQL hinzufügt

Für jede Aufgabe unten nennt die mittlere Spalte den Supabase-Dienst, der sie übernimmt – entnommen der Architekturseite von Supabase und dem README für das selbstgehostete Setup in v0.8.3.

Unsere Empfehlung für einen häufigen Fall: Eine Next.js-, React- oder Mobile-App ohne bisherigen Servercode profitiert am meisten von Supabase. Ohne Supabase ist all das Code, den du vor dem Launch schreiben müsstest. Ein Team, das bereits ein Backend mit Rails, Django oder Express hat, hat von den zehn zusätzlichen Diensten wenig.

DreamHost bietet beides als Server mit vorinstallierter Software an, Supabase VPS Hosting und PostgreSQL VPS Hosting, auf denselben Stack-Tarifen zu denselben Preisen. Wenn du gerade Supabase Cloud nutzt und dich fragst, ob ein Server günstiger wäre, lies zuerst, was Supabase Cloud kostet, wenn du wächst. Wenn du einen verwalteten PostgreSQL-Dienst gegen reines PostgreSQL auf einem Server abwägst, lies, was verwaltetes Postgres im Vergleich zu einem Server kostet.

Was am ersten Tag funktioniert hat

Wir haben jede Aufgabe direkt nach der Installation auf Supabase ausprobiert, ohne eigenen Code außer Testskripten, und alle sieben funktionierten.

• Einen Nutzer anmelden und ein Token erhalten. Wir haben den Nutzer über die Admin-API angelegt, da das Standard-Setup keinen Mailserver für Bestätigungs-E-Mails hat.
• Eine Tabelle per HTTP unter einer Row-Level-Security-Policy lesen und schreiben. Der angemeldete Nutzer sah seine 1 Zeile, eine Anfrage ohne angemeldeten Nutzer bekam 0 Zeilen.
• Eine Datei hochladen und dieselben Bytes herunterladen. Wir nutzten einen privaten Bucket, und der Download stimmte Byte für Byte überein.
• Ein Bild skalieren. Der imgproxy-Dienst machte aus einem 800x600-PNG eines mit 200 Pixeln Breite.
• Eine Serverfunktion aufrufen. Die mitgelieferte hello-Funktion antwortete.
• Ein Ereignis erhalten, wenn eine Zeile hinzukommt. Ein supabase-js-Client erhielt die neue Zeile 283 ms nach dem Insert.
• Ein Web-Dashboard öffnen. Studio fragte zuerst nach dem Login.

Auf reinem PostgreSQL 17 haben wir die beiden Aufgaben getestet, die die Datenbank allein erledigt. Dieselbe Row-Level-Security-Policy funktionierte in SQL, und LISTEN und NOTIFY übertrugen ein Ereignis zwischen zwei SQL-Sitzungen. Der Rest braucht Software über die Datenbank hinaus: eine HTTP-API, Anmeldung, Dateispeicher, Serverfunktionen, eine Browserverbindung für Live-Updates und ein Dashboard.

Realtime brachte unseren ersten Durchlauf ins Stolpern: Der supabase-js-Client meldete nach 35 ms, dass er abonniert hatte, und die Zeile, die wir direkt danach einfügten, kam nie an. Beim zweiten Durchlauf haben wir die Systemereignisse des Channels protokolliert: Der Client meldete subscribed nach 32 ms, und die eigene Meldung Subscribed to PostgreSQL von Realtime kam etwa 2,4 Sekunden später. Wenn deine App direkt nach dem Abonnieren eine Zeile schreibt, lausche auf das system-Ereignis des Channels und warte auf diese Meldung, bevor du einfügst.

Was beide von deinem Server verlangen

Supabase veröffentlicht Größenangaben für seinen Stack. PostgreSQL tut das nicht, also schließen unsere Messungen die Lücke. In der Tabelle steht Supabase für das selbstgehostete Setup v0.8.3 und PostgreSQL für reines PostgreSQL 17.

Die Zeilen von Speicher im Leerlauf bis Erweiterungen sind unsere eigenen Messungen vom 19. Oktober (8-GB-VM) und 20. Oktober 2026 (4-GB-VM), beschrieben unter So haben wir gemessen. Die Zeiten gelten für bereits heruntergeladene Images. Die Anzahlen stammen aus der Compose-Datei von Supabase beim Tag self-hosted/v0.8.3, die Download-Größen aus den Tag-Daten auf Docker Hub und die Anforderungen aus der Dokumentation des jeweiligen Herstellers, alle abgerufen am 16. Oktober 2026.

Logs & Analytics sind im Standard-Setup von Supabase deaktiviert, um den Speicherbedarf zu senken. Du aktivierst sie mit einer Override-Datei, die Logflare und Vector hinzufügt und die Anforderungen des Stacks erhöht.

Stack 4 erfüllt das Minimum von Supabase. Stack 8 bringt den empfohlenen RAM und Speicherplatz, bleibt aber bei 2 vCPU. Stack 16 ist der kleinste Tarif, der alle empfohlenen Werte von Supabase erfüllt – mit 4 vCPU, 16 GB RAM und 250 GB NVMe-Speicher laut der Supabase-VPS-Seite. Deshalb ist er unsere Empfehlung für die Produktion, und Stack 8 eignet sich für eine kleine App oder eine Staging-Kopie.

Unser 4-GB-Durchlauf zeigt, dass der Standard-Stack im Leerlauf auf Stack 4 passt. Alle 11 Container liefen ohne Neustart weiter, und ihr Speicher pendelte sich bei etwas mehr als einem Drittel der 3.904 MiB der VM ein. Die Images belegten etwa 9,7 GB Speicherplatz, deutlich innerhalb der 75 GB von Stack 4.

Derselbe Stack brauchte auf der 4-GB-VM etwa anderthalbmal so viel Speicher wie auf der 8-GB-VM. Studio, Realtime und der Pooler legten um 16 bis 22 % zu, fünf kleine Dienste um das Zwei- bis Siebenfache, imgproxy etwa von 13 MiB auf 94 MiB. Wir haben jedes Setup nur einmal getestet und können den Unterschied nicht erklären. Wir würden daher für Supabase im Leerlauf 1 bis 1,5 GB einplanen und zusätzlich für den Traffic deiner App dimensionieren.

Für PostgreSQL allein würden wir eine Produktionsdatenbank auf Stack 8 betreiben, den Tarif, den die PostgreSQL-VPS-Seite mit Für Apps im Produktivbetrieb beschreibt. Stack 4, beschrieben mit Für schlanke Apps und Einzelprojekte, reicht für den Anfang. Laut der Seite ist der Wechsel von Stack 4 auf Stack 32 unkompliziert, und deine Umgebung zieht mit um. Um den Server für alles andere zu dimensionieren, was du darauf betreibst, lies, welchen VPS-Tarif du brauchst.

Was dir reines PostgreSQL überlässt

Dein Backend übernimmt diese Aufgaben, und Rails und Django bringen vieles davon mit. Rails enthält einen Authentifizierungs-Generator, Active Storage kümmert sich um Uploads und Bildvarianten, und Action Cable stellt dem Browser WebSockets bereit. Django hat ein integriertes System zur Nutzerauthentifizierung, und Channels ergänzt WebSockets. Eine Express-App fügt all das über Bibliotheken hinzu, zum Beispiel Socket.IO für eine Live-Verbindung in beide Richtungen zwischen Browser und deinem Server.

PostgreSQL selbst deckt einen Teil der Liste ab. Seine Row Security Policies legen für jeden Nutzer fest, welche Zeilen eine Abfrage zurückgibt oder ändert, und die Zugriffsregeln von Supabase sind genau diese Richtlinien. LISTEN und NOTIFY senden ein Ereignis an jede Datenbanksitzung, die zuhört, sodass ein Worker in deinem Backend auf neue Zeilen reagieren kann. Ein Browser öffnet keine Datenbanksitzungen, deshalb laufen Live-Updates im Browser über einen eigenen WebSocket-Server wie Action Cable, Channels oder Socket.IO. Erweiterungen wie pgvector und PostGIS lassen sich auf unserem PostgreSQL-Server mit vollem Root-Zugriff installieren.

Wenn dir vor allem die automatische API fehlen würde, kannst du PostgREST eigenständig betreiben. Es ist der Webserver hinter der REST-API von Supabase, und laut seinem README serves a fully RESTful API from any existing PostgreSQL database.

Selbstgehostetes Supabase im Alltag betreiben

Die Self-Hosting-Seite von Supabase listet auf, was du übernimmst, wenn du es betreibst: Serverpflege, Aktualisierung von Betriebssystem und Diensten, Postgres-Wartung, Hochverfügbarkeit sowie Backups und Wiederherstellung.

• HTTPS. Das eigene Docker-Setup von Supabase antwortet über unverschlüsseltes HTTP, was auf einem Testsystem in Ordnung ist. Für den Produktivbetrieb setzt der Proxy-Leitfaden von Supabase Caddy oder Nginx mit Let’s Encrypt vor das Gateway.
• E-Mail. Die standardmäßigen Docker-Einstellungen von Supabase aktivieren die E-Mail-Registrierung mit Bestätigung und leiten Mails an einen Container, der nur in der Entwicklungsdatei von Supabase existiert. Richte deinen eigenen SMTP-Server ein, bevor sich echte Nutzer registrieren, sonst werden keine Bestätigungs- und Passwort-Reset-E-Mails verschickt.
• Updates. Laut dem Docker-Leitfaden von Supabase erscheint etwa einmal im Monat ein stabiler Snapshot. Das Update-Skript führt die Einstellungen des neuen Releases mit deinen zusammen. Danach ziehst du die neuen Images und erstellst die Container neu. Mach vorher ein Backup.
• Projekte. Eine Installation betreibt ein Projekt. Das selbstgehostete Studio kann nicht mehrere Organisationen oder Projekte verwalten, daher bekommt eine zweite App ihre eigene Installation.

Die Anleitung zum Selbsthosten enthält die Einrichtungsschritte, und der Docker-Leitfaden von Supabase ist die Referenz für jede Einstellung.

So haben wir gemessen

DreamHost hat beide Stacks am 19. Oktober 2026 auf einer lokalen Test-VM mit 2 vCPU und 7.922 MiB Arbeitsspeicher betrieben: Ubuntu 24.04.4 auf arm64, unter Colima auf einem Mac mit Apple Silicon. Unsere Tarife laufen auf x86-Prozessoren vom Typ AMD EPYC. Das war also kein DreamHost-Server, und die Image-Größen unterscheiden sich je nach Prozessor. Deshalb nennt die Tabelle auch die Downloadgröße für x86.

Supabase lief aus dem veröffentlichten Docker-Ordner v0.8.3, mit Secrets aus den eigenen Schlüsselskripten von Supabase. PostgreSQL lief aus der Beispiel-Compose-Datei von Docker Hub, fixiert auf postgres:17.11 und ohne den Adminer-Dienst. Jeder Speicherwert ist der Median aus 12 Messungen mit docker stats, eine alle 5 Sekunden, beginnend 10 Minuten nach dem Start. Die Images haben wir heruntergeladen, bevor wir die Startzeiten gemessen haben.

Am 20. Oktober haben wir Supabase erneut auf einer zweiten VM in der Größe von Stack 4 betrieben, mit 2 vCPU, 3.904 MiB Arbeitsspeicher und ohne Swap, mit denselben Ubuntu- und Docker-Versionen. Dafür nutzten wir eine frische Kopie desselben Ordners v0.8.3, neue Secrets und dieselben 12 Messungen nach 10 Minuten. Auf dieser VM lief außerdem eine kleine, nicht damit zusammenhängende Test-App mit etwa 180 MiB. Sie ist in keinem der genannten Supabase-Werte enthalten.

Wir haben jedes Setup nur einmal ausgeführt, daher gibt es keine Streuung anzugeben. Die Durchläufe decken einen Stack im Leerlauf ab und das, was direkt nach der Installation funktioniert. Eine App unter Last oder eine Woche Laufzeit decken sie nicht ab, und Logs & Analytics haben wir nicht eingeschaltet getestet.

FAQ zu Supabase oder reinem PostgreSQL