Was kostet Supabase, wenn du wächst, und wann ist ein Server günstiger?

Solange dein Projekt auf eine Micro-Instanz passt und innerhalb der enthaltenen Kontingente bleibt, macht das Compute-Guthaben die Plangebühr zur gesamten Rechnung. Ein Staging-Projekt, eine größere Instanz und Traffic über die enthaltenen Kontingente hinaus bringen jeweils eine eigene Position mit. In unserem größten Beispiel war die Gebühr für monatlich aktive Nutzer die größte Einzelposition, weil sie jenseits der 100.000 Nutzer, die Pro enthält, immer weiter steigt.

Wofür du bei Supabase Pro bezahlst

Über die enthaltenen Kontingente hinaus werden Nutzer, Egress, Speicher, Dateien und Funktionsaufrufe jeweils zu einem eigenen Tarif abgerechnet, laut der Preisseite von Supabase.

Die Abrechnungsdokumentation von Supabase nennt vier Regeln, die die Rechnung erhöhen, sobald deine App wächst:

• Das Compute-Guthaben bezahlt nur Compute. Laut der Compute-Dokumentation von Supabase bekommst du 10 $ im Monat. Das reicht für eine Micro-Instanz, und nichts davon fließt in Egress, Nutzer oder Speicher.
• Jedes Projekt bekommt seine eigene Compute-Instanz. Eine Staging-Kopie der Produktion fügt daher eine zweite Compute-Position hinzu, die das eine Guthaben nicht abdeckt.
• Speicher wird nach der Größe abgerechnet, die Supabase dir zuteilt. Laut der Dokumentation zur Datenbankgröße wächst der Speicher jedes Mal um 50 %, wenn deine Datenbank 90 % davon erreicht. Eine 20-GB-Datenbank landet so auf einem 27-GB-Speicher. Du zahlst für die 27 GB, abzüglich der 8 GB, die Pro enthält.
• Pro enthält 8 GB Speicher pro Projekt, und jedes weitere GB kostet 0,125 $ im Monat.

Um deinen eigenen Monat zu berechnen, öffne die Nutzungsseite und addiere diese Posten der Reihe nach:

1. Beginne mit 25 $ für den Plan.
2. Addiere das Compute jedes Projekts zu den gerundeten Monatspreisen von Supabase (10 $ Micro, 15 $ Small, 60 $ Medium, 110 $ Large) und ziehe dann einmal das Guthaben von 10 $ ab. Compute wird stundenweise abgerechnet. Ein Projekt, das nur einen Teil des Monats lief, kostet weniger.
3. Addiere 0,00325 $ für jeden monatlich aktiven Nutzer über 100.000. Das sind 32,50 $ pro 10.000.
4. Addiere 0,09 $ für jedes GB Egress über 250 GB, dazu 0,03 $ für jedes GB gecachten Egress über dessen eigene 250 GB.
5. Addiere 0,125 $ für jedes GB Speicher über 8 GB in jedem Projekt. Nimm dafür die Speichergröße, die für das Projekt angezeigt wird.
6. Addiere 0,0213 $ für jedes GB Dateien über 100 GB und 2 $ für jede Million Edge-Function-Aufrufe über 2 Millionen.
7. Addiere 2,50 $ für jede Million Realtime-Nachrichten über 5 Millionen und 10 $ für je 1.000 Spitzenverbindungen über 500.
8. Addiere alle Add-ons, die du aktiviert hast, etwa 100 $ im Monat für 7 Tage Point-in-Time-Recovery.

Warum Projekte den Free-Plan verlassen

Free umfasst bis zu 2 aktive Projekte mit jeweils 50.000 monatlich aktiven Nutzern, einer 500-MB-Datenbank, 5 GB Egress und 1 GB Dateispeicher, laut der Preisseite von Supabase. Wenn dein Projekt nach einer ruhigen Woche eingeschlafen ist, bist du an eine der Grenzen von Free gestoßen: Ein Free-Projekt pausiert nach einer Woche ohne Aktivität, und seine Datenbank wird schreibgeschützt, sobald sie 500 MB überschreitet. Automatische Backups gibt es auch nicht. Supabase rät Free-Nutzern deshalb, ihre Daten selbst mit der CLI zu exportieren und Kopien an einem anderen Ort aufzubewahren.

Bezahlte Projekte pausieren nicht wegen Inaktivität, und Pro bewahrt tägliche Backups sieben Tage lang auf.

So funktioniert das Ausgabenlimit bei einer wachsenden App

Angenommen, dein Egress überschreitet am 20. des Monats 250 GB. Bei Pro ist das Ausgabenlimit standardmäßig aktiv, daher wird Egress über 250 GB vom 20. bis zum nächsten Abrechnungszeitraum blockiert. Das gilt für jeden abgedeckten Posten über seinem Kontingent, laut der Dokumentation von Supabase dazu, wie das Ausgabenlimit funktioniert.

Bei aktivem Limit wächst der Speicher eines Pro-Projekts außerdem nicht über 8 GB hinaus. Mit dem Ausgabenlimit kannst du kein Budget und keine Warnung für eine einzelne Position festlegen. Du kannst es auch nicht für manche Positionen ein- und für andere ausschalten.

Drei App-Größen, Posten für Posten berechnet

Jedes Beispiel nutzt Supabase Pro im Monatsplan, in US-Dollar vor Steuern, mit den gerundeten monatlichen Compute-Preisen von Supabase. Die Nutzung ist unsere Annahme, also setz deine eigenen Zahlen ein:

• Nicht gecachter Egress wächst um etwa 10 MB pro Nutzer und Monat. Das ist unser runder Wert für eine schlanke App; deine Nutzungsseite zeigt deinen eigenen Wert. Die stärker genutzte App liefert außerdem 500 GB aus dem Cache von Supabase aus.
• Die Speichergrößen sind unsere Schätzung nach der Wachstumsregel von Supabase: 8 GB zu Beginn, dann jeweils die Hälfte mehr, sobald die Datenbank 90 % des Speichers erreicht. Supabase rundet möglicherweise.
• Die beiden größeren Apps betreiben ein Staging-Projekt auf Micro-Compute. Das Nebenprojekt nicht.
• Point-in-Time-Recovery (PITR) wird extra berechnet, mit 100 $ im Monat für sieben Tage Verlauf, und setzt mindestens Small-Compute voraus.

Ein Nebenprojekt, das gerade aus Free herausgewachsen ist

Angenommen, du hast 5.000 Nutzer, eine 2-GB-Datenbank, 50 GB Egress und 5 GB hochgeladene Dateien. Damit bleibt jeder Zähler deutlich innerhalb seines Pro-Kontingents, und das Compute-Guthaben gleicht die Micro-Instanz aus.

Du musst das Ausgabenlimit nicht abschalten. Point-in-Time-Recovery erhöht die Rechnung, weil sie eine eigene Gebühr mitbringt und dich von der Micro-Instanz wegbringt, die das Guthaben bezahlt.

Ein wachsendes SaaS mit 40.000 Nutzern

Dieses Beispiel ergänzt ein Staging-Projekt, damit niemand eine Schemaänderung zuerst an der Produktion ausprobiert. Es hat 40.000 monatliche Nutzer, eine 20-GB-Datenbank, 400 GB Egress, 60 GB Dateien und eine Million Edge-Function-Aufrufe.

Von dem, was gegenüber dem Nebenprojekt neu hinzukommt, entfällt etwa die Hälfte auf Staging und eine größere Produktionsinstanz. Der Rest geht auf Überschreitungen bei Speicher und Egress zurück. Diese Überschreitungen sind auch der Grund, warum du bei dieser Rechnung zum ersten Mal das Ausgabenlimit abschalten musst.

Eine stärker genutzte App mit 200.000 Nutzern

Bei 200.000 Nutzern überschreitest du das Pro-Kontingent bei fast jeder Position, die mit der Nutzerzahl wächst. Dieses Beispiel geht von 2 TB regulärem Egress aus, plus 500 GB aus dem Cache von Supabase, der ein eigenes Kontingent und einen niedrigeren Tarif hat. Wir nehmen an, dass die Produktion auf Large-Compute mit 2 dedizierten vCPUs und 8 GB RAM läuft.

Eine kleinere Instanz würde diese Rechnung kaum senken, da Compute nach Abzug des Guthabens weniger als ein Fünftel der Summe ausmacht. Die Nutzergebühr steigt mit jedem neuen aktiven Nutzer über 100.000 weiter.

Supabase im Vergleich zu einem Server

Die Tabelle stellt die drei Supabase-Rechnungen einem selbstverwalteten Server mit vorinstalliertem Supabase gegenüber. Der Server hat keine Gebühr pro Nutzer, und die Bandbreite ist in jedem Plan unbegrenzt (es gilt Fair Use). Es gibt also keine Datentransfer-Position, die du im Blick behalten musst. Sein Preis ändert sich, wenn der Einführungspreis nach 3 Monaten endet oder wenn du aus dem Plan herauswächst und auf einen größeren wechselst.

Die Serverspalte zeigt den Einführungspreis und den Verlängerungspreis. Wir verwenden für jede Schwelle in diesem Guide den Verlängerungspreis. Schon bevor du deine Zeit mitrechnest, zahlt das wachsende SaaS an Supabase mehr als diesen Preis. Stack 16 steht in der Tabelle, weil es unser kleinster Plan ist, der alle empfohlenen Self-Hosting-Anforderungen von Supabase erfüllt. Stack 8 hat genug RAM und Speicher, aber seine 2 vCPU erreichen nur das Minimum von Supabase. Die 4 vCPU von Stack 16 entsprechen dagegen den 4 Kernen, die Supabase empfiehlt:

Supabase bezeichnet sein Minimum als geeignet für Entwicklung und kleine bis mittlere Produktions-Apps. Genau dort passt Stack 8.

Was der Stack belegt, bevor deine Nutzer kommen

Der Preisvergleich gilt nur, wenn der Stack auf den Plan passt. Deshalb haben wir das eigene selbstgehostete Docker-Setup von Supabase, Release v0.8.3, auf zwei Testmaschinen laufen lassen und den Arbeitsspeicher abgelesen, nachdem er sich eingependelt hatte. Beide hatten 2 vCPU. Eine hatte 8 GB Arbeitsspeicher, die andere 4 GB, so viel wie das Minimum von Supabase und Stack 4.

Die Images für diese 11 Container belegten etwa 9,7 GB Speicherplatz. Der Arbeitsspeicher des Stacks selbst ist nur ein kleiner Teil der 16 GB von Stack 16. Fast alles bleibt also für den Cache deiner Datenbank und deine Nutzer übrig. Der Lauf mit 4 GB zeigt, dass der Stack auch auf einer Testmaschine von der Größe unseres kleinsten Plans startet und im Leerlauf läuft. Keiner der Läufe hatte Traffic, daher sagt keiner aus, wie viele Nutzer ein Plan trägt. Die Planauswahl stützt sich weiterhin auf die 4 Kerne, die Supabase empfiehlt. Mit dem Lasttest in den Schritten weiter unten prüfst du das für deine App.

In der Cloud hat die Large-Compute-Instanz der stärker genutzten App 8 GB RAM. Auf deinem Server teilt sich Postgres die 16 GB mit Auth, Storage, Realtime und dem Rest des Stacks.

Was im Serverpreis nicht enthalten ist

Für den Planpreis bekommst du einen Server, auf dem der Supabase-Stack läuft. Was nicht dazugehört, steht auf der Self-Hosting-Seite von Supabase. Branching, verwaltete Backups, PITR, erweiterte Metriken, Analytics und Vector Buckets, ETL und die Management-API gibt es nur in der Cloud.

In der Rechnungstabelle fehlen außerdem E-Mail und Backup-Speicher. Laut dem Docker-Leitfaden zum Selbsthosten von Supabase brauchst du einen produktionsreifen SMTP-Server, um Registrierungs- und Passwort-E-Mails zu versenden. Plane also einen Dienst für Transaktions-E-Mails ein. Deine Backups gehören an einen anderen Ort als den Server selbst, etwa in S3-kompatiblen Speicher. Auf der Serverseite zahlst du beides zusätzlich zum Plan. Wir haben diese Kosten nicht berechnet, weil sie von deinem E-Mail-Volumen abhängen, davon, wie viel du speicherst, und wie lange du Backups aufbewahrst.

Die 60-GB-Datenbank und die 120 GB an Dateien der stärker genutzten App passen auf 250 GB Speicherplatz, allerdings mit weniger Reserve, als es aussieht: Betriebssystem, Docker-Images (in unserem Test etwa 9,7 GB für die von Supabase), Logs und eine laufende Wiederherstellung brauchen ebenfalls Platz. Speichere Backups woanders und richte beim Einrichten des Servers eine Warnung für freien Speicherplatz ein.

Auch Staging fehlt auf der Serverseite, denn selbstgehostetes Supabase betreibt ein Projekt pro Stack. Eine Staging-Kopie bedeutet also einen zweiten Stack, entweder auf demselben oder auf einem zweiten Server. Zwei Stacks auf einem Server haben wir nicht getestet. Lässt du zum Vergleich auch auf der Cloud-Seite Staging weg, sinkt die SaaS-Rechnung um 10 $ auf 45,88 $ und die der stärker genutzten App auf 627,82 $. Auch ohne Staging bleibt das SaaS unter dem Break-even-Punkt, den du im nächsten Abschnitt siehst, und die stärker genutzte App liegt deutlich darüber.

Wo der Server gewinnt, wenn deine Zeit mitzählt

Routinewartung auf deinem eigenen Server bedeutet Betriebssystem-Updates, neue Docker-Images, einen Blick in die Logs und die Prüfung, ob das Backup der letzten Nacht gelaufen ist. Laut der Schätzung in unserem Leitfaden So hostest du Supabase selbst, und darauf verzichtest du kommt das alles auf ein bis zwei Stunden im Monat. Der Medianlohn 2025 für Softwareentwickler, QA-Analysten und Tester in den USA liegt laut dem Bureau of Labor Statistics bei 64,44 $ pro Stunde. Damit kosten diese Stunden 64,44 $ bis 128,88 $ im Monat.

Addiere diese Stunden zum Verlängerungspreis des Servers aus der Tabelle oben. Hier siehst du, ab welcher Supabase-Rechnung der Server samt Wartung günstiger wird. Die Beispielmonate sind unsere eigene Einschätzung, wann wie viel Wartung anfällt:

Die Rechnung der stärker genutzten App liegt sogar über der Acht-Stunden-Grenze. Jede Stunde verschiebt die Grenze um den Wert deiner Stunde. Ist deine Stunde also 100 $ wert, liegt die Ein-Stunden-Grenze bei etwa 135 $. Rechne auf der Serverseite außerdem Backup-Speicher, einen E-Mail-Dienst und eine einmalige Migration dazu.

Mit PITR liegt die Rechnung des wachsenden SaaS von 155,88 $ innerhalb der Spanne für ein bis zwei Stunden, also etwa 100 $ bis 164 $. Ein selbstgehosteter Server enthält aber keine verwaltete Point-in-Time-Recovery. Diese Wiederherstellung müsstest du selbst aufbauen und betreiben. Außerdem verzichtest du auf die täglichen Backups der letzten sieben Tage, die Cloud Pro für dich aufbewahrt. Wenn die Wiederherstellung der Grund ist, warum du für PITR zahlst, bleib bei der Cloud oder plane die Zeit ein, deine eigenen Backups aufzubauen und zu testen, bevor du umziehst. Die stärker genutzte App zahlt Supabase mehrere hundert Dollar im Monat mehr als für den Server und zwei Stunden deiner Zeit zusammen. Diese Ersparnis gilt aber nur, wenn ein Server deine Last trägt. Mach also einen Lasttest, bevor du damit rechnest.

Wenn deine App nur die Datenbank nutzt, findest du die Kosten für diesen Fall in unserem Leitfaden Was verwaltetes Postgres allein im Vergleich zu einem Server kostet. Wenn du noch überlegst, ob du überhaupt den kompletten Supabase-Stack brauchst, vergleicht unser Leitfaden Supabase oder reines PostgreSQL beide auf einem Server.

Bevor du die Produktion umziehst

In der GitHub-Diskussion von Supabase zum Selbsthosten beschrieb ein Entwickler die Sorge so:

Geh diese Schritte der Reihe nach durch, mit einer Kopie deiner Daten, während das Cloud-Projekt noch deine Nutzer bedient:

1. Ein aktuelles Backup auf dem Server wiederherstellen

   Sichere die Datenbank mit der Supabase CLI und stelle sie auf dem Server wieder her. Nutze dafür die Dump-Schritte im Leitfaden zu Backup und Wiederherstellung von Supabase. Miss die Dauer der Wiederherstellung, denn das ist der Datenbankanteil deiner Wiederherstellungszeit, falls der Server ausfällt. Probe außerdem einmal einen kompletten Neuaufbau.

2. Die Teile außerhalb der Datenbank umziehen

   Auth-Nutzer, Storage-Dateien und Edge Functions haben jeweils ihren eigenen Migrationsweg, also prüfe jeden einzeln. Registriere dann einen Testnutzer und stelle sicher, dass die E-Mail über deinen SMTP-Server ankommt.

3. Wie in der Produktion belasten

   Führe deine aufwendigsten Abfragen aus und öffne so viele Realtime-Verbindungen, wie deine Nutzungsseite zu Spitzenzeiten anzeigt. Behalte dabei den Arbeitsspeicher im Blick.

4. Backups einrichten, die den Server verlassen

   Schick nächtliche Backups weg vom Server, zum Beispiel in S3-kompatiblen Speicher. Stelle dann eines davon wieder her.

5. Umstellung und Rückweg planen

   Such dir eine ruhige Stunde aus. Behalte das Cloud-Projekt, bis der Server einen vollen Abrechnungszyklus gelaufen ist, und notiere, wie du zurückwechseln würdest.

Bleiben oder umziehen

Zähl deine eigenen Stunden, bevor du dich festlegst. Miss die Dauer der Wiederherstellung und des Lasttests oben, um zu sehen, was dich die Migration kostet. Protokolliere dann im ersten Monat deine Wartungszeit, um unsere Schätzung von ein bis zwei Stunden im Break-even durch deine eigenen Werte zu ersetzen.

Wie wir das berechnet und getestet haben

Die Cloud-Rechnungen hat DreamHost anhand der Preisliste und der Abrechnungsdokumentation von Supabase berechnet, Stand 28. September 2026. Am 21. Oktober haben wir die Preisliste erneut geprüft, und alle Tarife in den Tabellen waren unverändert. Die Nutzung in jedem Beispiel ist unsere Annahme, und wir haben kein Supabase-Cloud-Konto eröffnet, um sie zu testen.

Die Serverwerte hat DreamHost auf einer Test-VM (arm64) gemessen, nicht auf einem Server von DreamHost. Die Tests entstanden für unseren Leitfaden Supabase oder reines PostgreSQL, und diese Seite verwendet sie erneut. Sie liefen auf einem Mac unter Colima mit Ubuntu 24.04 und 2 vCPU: mit 8 GB Arbeitsspeicher am 19. Oktober 2026 und mit 4 GB am 20. Oktober. Der Docker-Ordner von Supabase in Version v0.8.3 lief wie veröffentlicht. Jeder Speicherwert ist der Median aus 12 Messungen mit docker stats, im Abstand von 5 Sekunden, 10 Minuten nach dem Start. Unsere Pläne laufen auf x86-Prozessoren von AMD EPYC, daher weichen die Image-Größen auf deinem Server ab.

Was wir nicht getestet haben: Traffic oder Last jeglicher Art, eine Woche Laufzeit, 4 vCPU, das Add-on Logs & Analytics, eine Wiederherstellung und zwei Supabase-Stacks auf einem Server. Jedes Setup lief einmal.

FAQ zu den Preisen von Supabase