Den TCO-Vergleich zwischen Supabase Cloud und self-hosted schreibt kein Vendor. Aus einem simplen Grund: Die ehrliche Rechnung fällt für keinen Anbieter eindeutig aus, und der Anbieter verdient nur an einer der beiden Antworten.
Supabase ist über die letzten Jahre vom Geheimtipp zum Standardbaustein vieler moderner Stacks geworden. Postgres, Auth, Storage, Realtime, Edge Functions – fertig verdrahtet, in Minuten produktiv. Genau diese Bequemlichkeit schiebt die eigentliche Entscheidung in den Hintergrund: Was kostet Supabase über drei Jahre wirklich, wenn das Projekt erfolgreich wird? Nicht im ersten Monat, sondern dann, wenn aus tausend Nutzern hunderttausend werden. Wer diese Frage erst stellt, wenn die erste vierstellige Rechnung kommt, hat sie zu spät gestellt.
Was kostet Supabase Cloud wirklich – und warum die Basispreise wenig aussagen
Die offizielle Preisseite ist erfreulich transparent, solange man genau liest. Supabase Cloud kennt vier Tiers: Free für 0 USD, Pro ab 25 USD/Monat, Team ab 599 USD/Monat und Enterprise mit individueller Kalkulation (Stand Juni 2026, Cloud-Preise sind volatil – im Konfigurator gegenprüfen). Das entscheidende Wort steht klein daneben: „from". Der Pro-Plan ist kein Festpreis, sondern ein Startpreis.
Was die 25 USD abdecken, ist konkret: 10 USD Compute-Credit, das eine Micro-Instanz trägt, 8 GB Disk pro Projekt, 100.000 monatlich aktive Nutzer und 250 GB Egress. Klingt großzügig, und für viele Projekte ist es das auch. Der Punkt ist, was *danach* passiert. Egress kostet 0,09 USD pro GB, Disk 0,125 USD pro GB, jeder zusätzliche aktive Nutzer 0,00325 USD. Compute ist ein separates Add-on, stündlich abgerechnet, von Micro für rund 10 USD/Monat bis hinauf zu 16XL bei ca. 3.730 USD/Monat (die Add-on-Tabelle ändert sich häufiger als die Basispreise – als Größenordnung lesen, nicht als Festwert).
Das ist keine Kritik am Pricing. Es ist ehrlich nutzungsbasiert. Aber genau das ist der Mechanismus, den FinOps-Verantwortliche verstehen müssen: Die Kosten von Managed Services steigen mit dem Projekterfolg. Mehr Nutzer, mehr Traffic, mehr Daten, höhere Rechnung – nicht linear, sondern entlang von Schwellen, die man im Konfigurator erst sieht, wenn man sie überschreitet. Wer eine erfolgreiche Anwendung baut, bestraft sich auf der Infrastrukturseite selbst.
Hetzner und Supabase self-hosted: die Rechnung, die kein Verkäufer aufmacht
Supabase ist vollständig self-hostbar. Alle Kernkomponenten – Auth über GoTrue, PostgREST, Storage, Realtime, Kong als Gateway, Postgres selbst – laufen via Docker und Docker Compose auf eigener Infrastruktur. Das Haupt-Repo steht unter Apache-2.0, die Komponenten unter MIT-, Apache-2- und PostgreSQL-Lizenzen. Kein Lizenz-Trick, kein versteckter Enterprise-Riegel vor der Tür. Was Supabase Cloud betreibt, können Sie grundsätzlich selbst betreiben.
Rechnen wir das durch, mit echten Zahlen statt Hochglanz. Ein Hetzner AX41-NVMe – AMD Ryzen 5 3600, 64 GB RAM, zwei NVMe-SSDs, unlimitierter Traffic – liegt bei rund 39 €/Monat netto. Die belastbare Spanne 2026 reicht je nach Standort von etwa 37 bis 51 €, mit angekündigter Preisanpassung zum 15. Juni 2026 und Aufwärtstrend – den Live-Preis im Hetzner-Konfigurator prüfen. Auf dieser einen Maschine laufen Datenbank, Auth, Storage und API für eine Anwendung mit einigen tausend aktiven Nutzern komfortabel.
Dazu kommen zwei Posten, die viele unterschlagen. Erstens die saubere Erstimplementierung: Setup, Integration, Security-Hardening, Testing – einmalig 5.000–20.000 € Entwicklungsaufwand, abhängig von Komplexität und Compliance-Anforderungen. Zweitens der laufende Betrieb: bei vernünftiger Automatisierung 2–5 Stunden pro Monat für Updates, Monitoring und Backups. Diese Stunden sind planbar – das ist ihr entscheidender Charakter. Sie schwanken nicht mit dem Traffic.
Das 3-Jahres-Gesamtbild einer typischen mittelständischen Webanwendung mit self-hosted Open-Source-Stack landet erfahrungsgemäß bei 40.000–80.000 €, Setup und Betrieb eingerechnet. Ein vergleichbares Setup mit proprietären Managed-Services liegt im selben Zeitraum oft beim Doppelten, manchmal mehr. Ähnliche Muster sehen wir branchenübergreifend, etwa im TCO-Vergleich WordPress gegen Sanity und Next.js oder bei der grundsätzlichen Frage, was eine moderne Unternehmenswebsite wirklich kostet. Der Kernsatz bleibt: Die Kosten eines self-hosted Stacks sinken über die Zeit pro Nutzer; die Kosten von Managed Services steigen mit dem Projekterfolg.
Warum die Kurven sich kreuzen – und wo
Beide Modelle als Geraden zu denken, ist der häufigste Fehler. Es sind keine Geraden, sondern zwei Kurven mit unterschiedlicher Steigung.
Supabase Cloud beginnt günstig, fast kostenlos. Der Free-Plan deckt 500 MB Datenbank, 50.000 MAUs und 5 GB Egress – pausiert allerdings nach einer Woche Inaktivität, taugt also nur für Prototypen. Der Pro-Plan trägt erstaunlich weit. In den ersten Monaten eines Projekts ist Cloud schlicht billiger als jede self-hosted Alternative, weil keine Setup-Kosten anfallen und niemand Betriebsstunden investiert. Dann steigt die Kurve. Mit jedem Wachstumsschub kommen Egress, Compute und MAU-Overages dazu.
Self-hosting beginnt teuer. Die 5.000–20.000 € Setup stehen am Anfang, bevor der erste Nutzer sich eingeloggt hat. Danach ist die Kurve flach. Ob auf dem AX41 tausend oder zwanzigtausend Nutzer sitzen, ändert die Hardwarekosten kaum – ein dedizierter Server skaliert vertikal eine ganze Weile mit, bevor man über redundante Instanzen und eine separate DB-Schicht nachdenkt (realistisch 150–400 €/Monat für echte Hochverfügbarkeit).
Der Kreuzungspunkt liegt nicht bei einem festen Datum, sondern an einem Nutzungs- und Datenprofil. Faustregel aus der Praxis: Sobald Egress und Compute in der Cloud-Rechnung die fixen Hetzner-Kosten plus den monetarisierten Wartungsaufwand übersteigen – und das Projekt das Prototypstadium verlassen hat – kippt die Bilanz Richtung self-hosted. Bei datenintensiven Anwendungen mit viel Egress oder vielen aktiven Nutzern passiert das früher, als die meisten erwarten. Bei einer internen Tool-Datenbank mit überschaubarem Traffic vielleicht nie.
Self-hosted heißt Betriebsverantwortung – und die kostet
Hier wird es ehrlich. Self-hosting ist kein Knopf, den man drückt und vergisst. Es ist Betriebsverantwortung: Updates einspielen, Sicherheitspatches zeitnah ausrollen, Backups testen – nicht nur anlegen, testen –, Monitoring aufsetzen, im Ernstfall nachts ein Restore fahren. Diese Verantwortung verschwindet bei Managed Services nicht aus der Welt, sondern wandert zum Anbieter. Genau dafür zahlt man die Prämie.
Wer diese Verantwortung intern nicht abbilden kann oder will, sollte Managed ernsthaft in Betracht ziehen. Die Logik ist symmetrisch: Bei Managed steigen die Kosten, sinkt der Aufwand. Bei self-hosted sinken die Kosten, steigt der Aufwand. Keine Variante minimiert beides gleichzeitig. Wer das verspricht, verkauft etwas.
Das ist auch der Grund, warum wir self-hosting nicht jedem empfehlen, der danach fragt. Ein Stack, der einen authentifizierten Login mit eigenem Identity Provider braucht – etwa die Kombination, die ich im Detail im Artikel zu Supabase und Keycloak durchgerechnet habe – addiert weitere Betriebskomponenten, die jemand verstehen und pflegen muss. Betriebsverantwortung ist kein Nebensatz. Sie ist die Hälfte der Entscheidung.
Der unbequeme Punkt: die Stunde, die niemand verbucht
Jetzt zu dem Teil, den die meisten TCO-Rechnungen schönen. Die Self-hosting-Ersparnis ist nur dann echt, wenn die eigenen Betriebsstunden zum realen Stundensatz in die Rechnung gehen.
Ich sehe es regelmäßig: Ein CTO rechnet die Hardware gegen die Cloud-Rechnung und kommt auf eine satte Ersparnis. Was in der Rechnung fehlt, ist seine eigene Zeit und die seines Teams. Die 2–5 Stunden Wartung im Monat sind keine Gratis-Ressource. Bei einem realistischen Mischsatz von rund 120 € pro Entwicklerstunde sind das 240 bis 600 € monatlich, die in der ehrlichen Bilanz auftauchen müssen. Wer diese Stunden auf null rechnet, manipuliert das Ergebnis – nur eben zu seinen eigenen Ungunsten, weil die Überraschung später kommt.
Und sie kommt nicht im Durchschnitt. Sie kommt im Ausnahmefall. Der Durchschnitt sind ruhige zwei Stunden im Monat. Der Ausnahmefall ist die Nacht, in der ein fehlgeschlagenes Update die Datenbank lahmlegt und jemand das Backup zurückspielen muss – jemand, der weiß, wie das geht, und der erreichbar ist. Diese eine Nacht steht in keiner Tabelle, aber sie ist real. Wer self-hosting wählt, kauft nicht nur Server, sondern auch die Verpflichtung, dass diese Kompetenz im Haus vorhanden und verfügbar ist. Rechnet man sie ein, schrumpft die Ersparnis – und bei kleinen Projekten kippt sie ins Gegenteil.
Genau hier liegt die Grenze meiner eigenen These. Self-hosting ist nicht pauschal günstiger. Es ist günstiger oberhalb einer Schwelle, *und* unter der Bedingung, dass die Betriebskompetenz ohnehin vorhanden ist oder bewusst aufgebaut werden soll. Fehlt diese Bedingung, ist die scheinbare Ersparnis eine Buchhaltungsillusion.
Die Rechtsdimension, die in keiner Preistabelle steht
Ein Faktor, der TCO im engeren Sinn sprengt, aber zur Gesamtentscheidung gehört: der Speicherort der Daten. Supabase Cloud läuft auf AWS, die Region ist pro Projekt wählbar – Frankfurt, Paris, Zürich, Stockholm und weitere EU-Standorte stehen zur Verfügung. Das löst die DSGVO-Frage nicht vollständig. Supabase Inc. bleibt US-inkorporiert und damit potenziell dem US CLOUD Act unterworfen, unabhängig vom EU-Speicherort. Das ist eine juristische Einordnung aus Sekundärquellen, keine Infrastruktur-Limitierung – aber für regulierte Branchen ein Posten im Vendor Risk Management. Wer self-hosted auf deutscher Hardware betreibt, nimmt diese Frage vom Tisch.
Das ist kein reines Cloud-Problem. Dieselbe Spannung trägt jeder US-Anbieter, weshalb der Vergleich Supabase gegen Firebase aus europäischer Perspektive bei Firebase noch schärfer ausfällt: kein Self-Hosting, ausschließlich Google Cloud. Die Souveränitätsfrage ist Teil der Make-or-Buy-Entscheidung, nicht ein nachgelagertes Compliance-Detail. Wer von einer bestehenden Firebase-Basis kommt, findet im Leitfaden zur Migration von Firebase zu Supabase die technischen Stolpersteine – die Kostenfrage entscheidet sich aber vorher.
Was ich Entscheidern rate
Rechnen Sie beide Kurven, nicht beide Geraden. Setzen Sie ein realistisches Wachstumsszenario an – nicht den heutigen Monat, sondern den, in dem das Projekt funktioniert – und tragen Sie die Cloud-Usage-Posten genauso ein wie die Hetzner-Fixkosten und Ihre Betriebsstunden zum echten Stundensatz. Wenn Sie Ihre eigene Zeit auf null setzen, lügen Sie sich in die Tasche, und die Wahrheit kommt nachts.
Für ein frühes Projekt ohne Ops-Team ist Supabase Cloud die richtige Antwort – schneller Start, keine Betriebslast, kalkulierbar bis zur ersten echten Skalierung. Ab dem Punkt, an dem das Projekt trägt, an dem Egress und Compute spürbar werden und die Betriebskompetenz im Haus ist oder sein soll, dreht die Bilanz. Dann ist self-hosted auf Hetzner nicht nur billiger, sondern auch souveräner. Die strategische Logik dahinter, dass Hosting-Entscheidungen mehr über eine Anwendung aussagen als die Performance allein, gilt hier doppelt. Wer Supabase ohne Vendor-Lock-in betreiben und die Tiefe des Stacks verstehen will, findet im Supabase-Hub für Entscheider die Einordnung. Die Frage ist nie, ob managed oder self-hosted *generell* günstiger ist. Die Frage ist, wo auf Ihrer Wachstumskurve Sie gerade stehen – und ob Sie ehrlich genug rechnen, um das zu sehen.
