Wenn Sie Supabase und Firebase nebeneinanderlegen und Feature-Listen abhaken, vergleichen Sie das Falsche. Die eigentliche Entscheidung steht in keiner der beiden Spalten.
Firebase ist ein exzellentes Produkt. Für ein Mobile-MVP, das in sechs Wochen live gehen soll, gibt es kaum etwas Reibungsloseres. Genau deshalb taucht der Vergleich mit Supabase überhaupt erst auf: Beide versprechen Backend-as-a-Service, beide nehmen Ihnen Auth, Datenbank, Storage und Realtime ab. Auf dieser Ebene lässt sich trefflich streiten, ob NoSQL oder relational, ob Firestore-SDK oder PostgREST. Da bleiben die meisten Vergleichsartikel hängen. Und genau diese Ebene entscheidet für ein europäisches Unternehmen unter DSGVO am wenigsten.
Warum Supabase oder Firebase keine Feature-Frage ist
Die Frage Supabase oder Firebase wird fast immer als Technikfrage gestellt und fast nie als das beantwortet, was sie für eine europäische Organisation tatsächlich ist: eine Souveränitäts- und Risikoentscheidung. Sobald personenbezogene Daten im Spiel sind, und das sind sie bei einem Authentifizierungs-Backend per Definition, verschiebt sich der Schwerpunkt. Nicht mehr "Welches SDK ist angenehmer?", sondern "Wer hat unter welchem Recht Zugriff auf unsere Daten, und wie kommen wir da wieder raus?"
Firebase ist Google. Das ist keine Polemik, das ist die Architektur. Firestore läuft ausschließlich auf Google Cloud, es gibt keine On-Premise-Variante, kein Private Deployment, keinen offengelegten Quellcode. Sie mieten einen Dienst, dessen Betreiber ein US-Konzern ist, und das bleiben Sie für die gesamte Lebensdauer der Anwendung. Supabase dagegen ist im Kern PostgreSQL, ergänzt um eine Schicht offener Komponenten, das Hauptrepository steht unter Apache-2.0-Lizenz. Sie wählen die EU-Region, oder Sie hosten den kompletten Stack selbst. Das ist kein gradueller Unterschied im Komfort. Das ist ein struktureller Unterschied in der Frage, wem Ihre Infrastruktur gehört.
Wer nur Features vergleicht, vergleicht die Oberfläche und ignoriert das Fundament. Und das Fundament ist es, das Sie in drei Jahren vor dem Vorstand rechtfertigen müssen, nicht die Developer Experience im Sprint zwei. Dass diese Backend-Wahl Teil einer größeren Souveränitätsentscheidung ist, wird klarer, wenn man sie im Kontext der gesamten Frage nach digitaler Souveränität im Stack betrachtet.
Firebase Datenschutz: Was der CLOUD Act mit Ihrer EU-Region macht
Hier wird es konkret, und hier wird es unbequem für die Firebase-Seite. Google LLC ist unter dem EU-US Data Privacy Framework selbst-zertifiziert, Sie können Datenübermittlungen also auf diese Rechtsgrundlage stützen, solange das DPF gültig ist. Das klingt nach erledigter Compliance. Ist es aber nur halb.
Das Data Privacy Framework deckt die Rechtsgrundlage für den Transfer. Es beseitigt nicht das Zugriffsrisiko. Diese Unterscheidung wird in Sales-Decks gern verwischt, und sie ist der Kern der Sache. Der US CLOUD Act, in Kraft seit 2018, verpflichtet US-Anbieter zur Herausgabe von Daten auf behördliche Anordnung, und zwar unabhängig vom physischen Speicherort. Das Gesetz knüpft am Anbieter an, nicht an der Geografie. Eine Firestore-Datenbank in der Region Frankfurt schützt Sie also juristisch nicht vor einem US-Zugriff, wenn der Betreiber ein US-Konzern ist. Die Mechanik ist in der Einordnung zum CLOUD Act nachzulesen, und sie gilt für Google so wie für jeden anderen US-Provider.
Dazu kommt die Wackeligkeit der Rechtsgrundlage selbst. Der EuGH hat mit Schrems I und Schrems II bereits zwei Vorgänger-Mechanismen für US-Transfers kassiert. Das DPF ist die dritte Konstruktion, und sie steht erneut unter Beobachtung: Das Latombe-Rechtsmittel ist 2026 beim EuGH anhängig, und das US-Aufsichtsgremium PCLOB war Anfang 2025 ohne Quorum. Das DPF bleibt gültig, bis ein Gericht anders entscheidet, das ist die ehrliche Lage. Aber wer Investitionssicherheit für eine fünf Jahre laufende Anwendung plant, baut sein Fundament ungern auf einen Mechanismus, dessen zwei Vorgänger annulliert wurden. Wer tiefer in diese Risikolage einsteigen will, findet die strategische Einordnung in unserem Beitrag dazu, ob unsere Daten in den USA noch sicher sind.
Das macht Firebase nicht illegal. Eine Firebase Alternative DSGVO-konform aufzustellen heißt nicht, Google sei verboten. Es heißt, dass Sie ein Restrisiko tragen, das Sie bewusst akzeptieren oder bewusst vermeiden sollten, statt es wegzuklicken.
Vendor Lock-in vermeiden: Der Exit ist die eigentliche Architektur
Die wichtigste Frage bei jeder Backend-Entscheidung lautet nicht "Wie komme ich rein?", sondern "Wie komme ich wieder raus?". Bei Firebase ist die ehrliche Antwort: schwer und teuer. Es gibt keinen Self-Hosting-Pfad. Wenn Google die Preise anzieht, ein Produkt einstellt oder die Lizenzbedingungen ändert, haben Sie keine Verhandlungsposition außer Abwandern, und Abwandern bedeutet Re-Implementierung, weil das Firestore-Datenmodell, die Security Rules und das proprietäre SDK nirgendwo sonst laufen.
Supabase dreht diese Logik um. Weil der Kern PostgreSQL ist, das meistgenutzte relationale Open-Source-Datenbanksystem, ist Ihr Datenmodell portabel. Ein PostgreSQL Backend läuft bei Supabase Cloud, bei jedem anderen Postgres-Hoster oder auf Ihrem eigenen Server. Der gesamte Supabase-Stack ist via Docker self-hostbar, Auth, Storage, Realtime und PostgREST inklusive. Der Exit ist nicht ein Notausgang, den der Anbieter zähneknirschend duldet. Er ist Teil der Architektur. Das ist der Unterschied zwischen einem Mietvertrag mit Kündigungsklausel und einem ohne.
Für die Frage, Vendor Lock-in vermeiden zu wollen, ist das die ganze Geschichte. Lock-in entsteht nicht dadurch, dass ein Wechsel unmöglich ist. Er entsteht dadurch, dass die Wechselkosten so hoch sind, dass Sie faktisch gefangen sind, lange bevor es jemand "Lock-in" nennt. Bei einem proprietären, nicht-self-hostbaren Dienst sind diese Kosten in die Architektur eingebaut. Wer den umgekehrten Weg gehen will, von Firebase weg, findet die konkreten Schritte und Stolperfallen in unserem Leitfaden zur Migration von Firebase zu Supabase, inklusive der Frage, wie Passwörter ohne Reset erhalten bleiben.
Was Firestore-Kosten mit Ihrem Wachstum machen
Es gibt einen zweiten Punkt, weniger juristisch und mehr betriebswirtschaftlich, und der in der Praxis genauso oft schmerzt. Firebase rechnet pay-as-you-go, und das klingt fair, bis das Produkt erfolgreich wird. Wir hatten Kunden, die bei wachsender Nutzerzahl die Firebase-Preistabelle neu lesen mussten, weil die Rechnung schneller stieg als die Nutzerbasis.
Der Grund liegt in der Kostenmechanik. Firestore berechnet pro gelesenem Dokument, und zusätzlich pro Index-Eintrag, ein Read je bis zu 1000 Index-Einträge, auch für Query-Treffer. Die Kosten skalieren also mit dem Zugriffs- und Abfrageverhalten, nicht linear mit der Datenmenge. Das ist genau die Dimension, die am schwersten vorherzusagen ist, weil sie davon abhängt, wie Ihre Nutzer die App tatsächlich benutzen. Die operativen Preise liegen laut Firestore-Pricing bei circa 0,06 Dollar je 100.000 Reads und 0,18 Dollar je 100.000 Writes, regions- und währungsabhängig und Stand Juni 2026, prüfen Sie den Live-Preis. Die einzelnen Beträge sind klein. Das Problem ist die Multiplikation mit einem Nutzungsverhalten, das Sie nicht kontrollieren.
Stellen Sie das einem self-hosted PostgreSQL-Stack gegenüber. Eine saubere Erstimplementierung, also Aufsetzen, Integration, Security und Testing, kostet einmalig grob 5.000 bis 20.000 Euro Entwicklungsaufwand. Der laufende Betrieb bei vernünftiger Automatisierung liegt bei 2 bis 5 Stunden im Monat für Updates, Monitoring und Backups, und die Hosting-Kosten für einen Einstieg bei einem deutschen Anbieter wie Hetzner bewegen sich im Bereich 20 bis 50 Euro im Monat. Das Entscheidende ist nicht die einzelne Zahl, sondern die Richtung: Die Kosten eines self-hosted Stacks sinken über die Zeit, während die Kosten eines nutzungsbasierten Managed-Dienstes mit dem Projekterfolg steigen. Wer das im Detail durchgerechnet sehen will, findet die Total-Cost-of-Ownership-Betrachtung in unserer TCO-Analyse zu Supabase in der Produktion.
Auch hier gilt die Fairness: Für ein Projekt mit unklarem Wachstum und kleiner Nutzerbasis ist pay-as-you-go genau richtig, weil Sie nichts zahlen, was Sie nicht nutzen. Der Mechanismus dreht sich erst gegen Sie, wenn Sie erfolgreich werden. Das ist die unangenehmste Variante eines Kostenmodells: eines, das Sie für Ihren eigenen Erfolg bestraft.
Wo Firebase tatsächlich besser ist
Jetzt der faire Teil, und ich meine das ernst, nicht als rhetorisches Feigenblatt. Firebase ist in mehreren Disziplinen schlicht ausgereifter, und das sollte in keiner Entscheidung untergehen.
Firestore hat echten Offline-Support. Das onSnapshot-Modell mit lokalem Cache und Conflict-Resolution ist für mobile Apps, die in Funklöchern funktionieren müssen, eine ernsthafte Stärke. Supabase Realtime streamt Postgres-Änderungen über WebSockets, bietet aber keine native Offline-Persistenz, das Client-Caching müssen Sie selbst bauen, etwa mit TanStack Query. Das ist Arbeit, die bei Firebase wegfällt.
Dann das Google-Mobile-Ökosystem. Push-Notifications über FCM, Crashlytics für Fehler-Reporting, Remote Config, Analytics, ML Kit, das alles greift bei Firebase nahtlos ineinander. Supabase hat dafür kein direktes Pendant. Push läuft über Expo oder FCM, angestoßen aus Edge Functions, und für Crashlytics oder Remote Config brauchen Sie Drittanbieter wie Sentry. Wenn Ihre Roadmap tief in diesem Ökosystem steckt, ist ein Wechsel kein freier Mittagstisch.
Und für die reine Geschwindigkeit von der Idee zum Mobile-MVP ist Firebase mit seinem Spark-Plan ohne Zahlungsdaten und dem polierten SDK schwer zu schlagen. Das ist real, das ist die dokumentierte Stärke der Firebase-Plantarife. Diese Stärke löst nur die Souveränitätsfrage nicht. Sie ist die Antwort auf "Wie schnell?", nicht auf "Wem gehört es und wie komme ich raus?".
Der unbequeme Punkt: Supabase Cloud läuft auch auf AWS
Hier muss ich ehrlich gegen meine eigene These argumentieren, sonst verkaufe ich Souveränität, die ich nicht liefere. Supabase Cloud läuft auf AWS. Das ist US-Konzern-Infrastruktur, genau wie Google Cloud. Wenn Sie Supabase als Managed-Dienst in der EU-Region buchen, wählen Sie zwischen Frankfurt, Irland, Paris, London, Zürich oder Stockholm, und Ihre Daten liegen physisch in Europa. Aber Supabase Inc. ist ein US-inkorporiertes Unternehmen, und damit greift dasselbe CLOUD-Act-Argument, das ich gegen Firebase ins Feld geführt habe.
Wer das verschweigt, betreibt genau die Verwischung, die ich Firebase-Sales vorgeworfen habe. Die EU-Region bei Supabase Cloud ist ein architektonisches Faktum, der Speicherort liegt in Europa, aber sie ist keine Compliance-Garantie gegen US-Behördenzugriff per se. Auf der Managed-Cloud-Ebene ist der Souveränitätsvorteil von Supabase gegenüber Firebase also kleiner, als die Marketing-Erzählung suggeriert. Beide sind US-Konzerne mit EU-Speicheroption.
Der Unterschied liegt woanders, und er ist trotzdem entscheidend: beim Exit. "Europäisch" im starken Sinn ist Supabase erst auf dem self-hosted Pfad, oder über die explizit gewählte EU-Region plus sauberen Auftragsverarbeitungsvertrag. Aber, und das ist der Punkt, dieser self-hosted Pfad existiert. Bei Firebase gibt es ihn nicht. Sie können bei Supabase mit der Managed Cloud schnell starten und später, wenn Datenkontrolle zur harten Anforderung wird, denselben Stack auf eigene Infrastruktur ziehen, ohne die Anwendung neu zu schreiben. Die Souveränität ist bei Supabase eine Option, die Sie ziehen können. Bei Firebase ist sie keine. Das ist der ehrliche, kleinere, aber belastbare Unterschied. Wer die Grundlagen des Supabase-Stacks noch nicht kennt, findet sie in unserer Einführung dazu, was Supabase eigentlich ist.
Was ich Entscheidern rate
Stellen Sie die Frage nicht im Sprint, sondern im Operating Model. Wenn Datensouveränität für Ihre Anwendung eine harte, nicht verhandelbare Anforderung ist, etwa weil Sie in einem regulierten Sektor unter NIS2 fallen oder besonders sensible personenbezogene Daten verarbeiten, dann ist Firebase strukturell die falsche Wahl, egal wie gut das SDK ist. Ein Backend ohne Self-Hosting-Exit, betrieben von einem US-Konzern unter CLOUD Act, ist ein Vendor Risk, das Sie nicht durch eine EU-Region wegkonfigurieren. Supabase gibt Ihnen denselben Komfort beim Start und zusätzlich einen Ausweg, den Sie ziehen können, wenn das Risiko real wird.
Wenn Datensouveränität dagegen keine harte Anforderung ist, Sie ein Mobile-MVP schnell validieren wollen und tief im Google-Ökosystem stecken, dann nehmen Sie Firebase und fühlen sich nicht schlecht dabei. Die ehrliche Frage, die Sie sich und Ihrem Dienstleister stellen sollten, ist diese: Empfiehlt jemand Firebase, weil es für Ihren Fall die richtige Architektur ist, oder weil es das ist, was er ohnehin am liebsten baut? Technologieentscheidungen sind nie nur technisch. Wer das ignoriert, kauft die Interessen seines Dienstleisters mit, ohne den Preis dafür je auf einer Rechnung zu sehen.
