Supabase oder Firebase: Warum die Wahl in Europa keine Feature-Frage ist

Wenn du Supabase und Firebase nebeneinanderlegst und Feature-Listen abhakst, vergleichst du 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 dir 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.

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. Du mietest einen Dienst, dessen Betreiber ein US-Konzern ist, und das bleibst du 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. Du wählst die EU-Region, oder du hostest den kompletten Stack selbst. Das ist kein gradueller Unterschied im Komfort. Das ist ein struktureller Unterschied in der Frage, wem deine Infrastruktur gehört.

Wer nur Features vergleicht, vergleicht die Oberfläche und ignoriert das Fundament. Und das Fundament ist es, das du in drei Jahren vor dem Vorstand rechtfertigen musst, 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.

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, du kannst 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 dich 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 du ein Restrisiko trägst, das du bewusst akzeptieren oder bewusst vermeiden solltest, statt es wegzuklicken.

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, hast du 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 dein Datenmodell portabel. Ein PostgreSQL Backend läuft bei Supabase Cloud, bei jedem anderen Postgres-Hoster oder auf deinem 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 du faktisch gefangen bist, 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.

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 deine 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üfe den Live-Preis. Die einzelnen Beträge sind klein. Das Problem ist die Multiplikation mit einem Nutzungsverhalten, das du nicht kontrollierst.

Stell 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 du nichts zahlst, was du nicht nutzt. Der Mechanismus dreht sich erst gegen dich, wenn du erfolgreich wirst. Das ist die unangenehmste Variante eines Kostenmodells: eines, das dich für deinen eigenen Erfolg bestraft.

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 musst du 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 direkt 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 brauchst du Drittanbieter wie Sentry. Wenn deine 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?".

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 du Supabase als Managed-Dienst in der EU-Region buchst, wählst du zwischen Frankfurt, Irland, Paris, London, Zürich oder Stockholm, und deine 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.

Du kannst 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 du ziehen kannst. 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.

Stell die Frage nicht im Sprint, sondern im Operating Model. Wenn Datensouveränität für deine Anwendung eine harte, nicht verhandelbare Anforderung ist, etwa weil du in einem regulierten Sektor unter NIS2 fällst oder besonders sensible personenbezogene Daten verarbeitest, 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 du nicht durch eine EU-Region wegkonfigurierst. Supabase gibt dir denselben Komfort beim Start und zusätzlich einen Ausweg, den du ziehen kannst, wenn das Risiko real wird.

Wenn Datensouveränität dagegen keine harte Anforderung ist, du ein Mobile-MVP schnell validieren willst und tief im Google-Ökosystem steckst, dann nimm Firebase und fühl dich nicht schlecht dabei.

Die ehrliche Frage, die du dir und deinem Dienstleister stellen solltest, ist diese: Empfiehlt jemand Firebase, weil es für deinen 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.