Supabase vs. Firebase 2026: Welches Backend für eine Web-App?

Für die meisten Web-Apps mit Nutzern, Konten und verknüpften Daten (SaaS, interne Tools, Kundenportale) ist Supabase die bessere Standardwahl: Die PostgreSQL-Datenbank bewältigt Relationen, Filter und Auswertungen mit gewöhnlichem SQL. Firebase passt besser, wenn Ihre App auf Echtzeit-Synchronisierung oder Offline-Nutzung auf dem Smartphone aufbaut oder Sie ohnehin in der Google Cloud arbeiten. Beide haben einen Gratis-Tarif, und beide skalieren. Der Unterschied liegt im Datenmodell, und das lässt sich später nur schwer ändern.

Dieser Leitfaden vergleicht beide Dienste an den Punkten, die für ein kleines Team oder eine KI-generierte App zählen: Datenmodell, Abfragen, Authentifizierung, Sicherheitsregeln, Speicher und Funktionen, Gratis-Tarife, Preise und Lock-in. Die Tarifdetails wurden im November 2026 auf den Preisseiten der Anbieter geprüft. Sie ändern sich, prüfen Sie sie also vor Ihrer Entscheidung noch einmal.

Die kurze Antwort in einer Tabelle

Supabase ist ein PostgreSQL-Backend mit Authentifizierung, Speicher und Funktionen. Firebase ist ein Google-Backend rund um die Dokumentdatenbank Firestore. Die Tabelle zeigt den Gegensatz Zeile für Zeile.

Datenmodell: Tabellen oder Dokumente

Supabase speichert Daten in verknüpften Tabellen, Firestore als Dokumente, die in Collections gruppiert sind. Diese Entscheidung prägt alles Weitere.

Eine Business-App ist voller Relationen: Ein Kunde hat Projekte, ein Projekt hat Aufgaben, eine Aufgabe hat Kommentare, eine Rechnung gehört zu einem Kunden. In PostgreSQL legen Sie diese Verbindungen mit Fremdschlüsseln fest, und die Datenbank erzwingt sie. In Firestore entscheiden Sie für jeden Screen, ob Sie Daten in ein Dokument verschachteln oder duplizieren, und die Kopien halten Sie selbst synchron. Duplizieren macht das Lesen schnell und einfach, aber jede Änderung eines Kundennamens muss dann viele Dokumente anfassen.

Firebase bietet inzwischen auch eine relationale Option: Laut Dokumentation gibt es eine verwaltete PostgreSQL-Datenbank auf Cloud SQL, die über die Firebase-SDKs erreichbar ist. Das ist ein eigenes Produkt neben Firestore. Prüfen Sie daher, welches ein Tutorial oder ein KI-generiertes Projekt tatsächlich verwendet.

Abfragen und Auswertungen

Wenn Sie je fragen werden „wie viele Bestellungen pro Kunde und Monat“, brauchen Sie SQL. In Supabase schreiben Sie das als eine Abfrage mit Join und Group by, oder Sie geben die Frage an ein Tabellenkalkulations- oder BI-Tool weiter, das direkt mit Postgres verbunden ist.

Firestore ist darauf ausgelegt, Dokumente über einen Pfad oder einfache Filter abzurufen, was in jeder Größenordnung schnell und günstig ist. Für Ad-hoc-Aggregationen über mehrere Collections ist es nicht gebaut. Teams ergänzen meist Zähler, die Funktionen pflegen, oder exportieren die Daten in ein anderes System für die Analyse. Für ein dashboardlastiges internes Tool ist dieser Mehraufwand real, bei einem Chat oder einem Feed fällt er selten ins Gewicht. Unser Leitfaden zum Thema interne Tools erstellen zeigt, warum Auswertungen oft zur Hauptfunktion werden.

Authentifizierung

Beide Dienste liefern eine fertige Authentifizierung mit E-Mail, OAuth-Anbietern und Sitzungen pro Nutzer, und beide nennen in ihren Gratis-Tarifen 50.000 monatlich aktive Nutzer. Für eine typische Web-App entscheidet die Authentifizierung nicht.

Zwei Unterschiede sind gut zu wissen. In Supabase liegen die Nutzer in Ihrer Postgres-Datenbank, sodass Sie sie mit Ihren eigenen Tabellen verknüpfen können. Bei Firebase ist die Anmeldung per Telefonnummer im kostenlosen Spark-Tarif nicht verfügbar und wird auf Blaze pro SMS berechnet. Wenn sich Ihre Nutzer mit der Telefonnummer anmelden, prüfen Sie diese Zeile zuerst. Mehr zur Supabase-Seite lesen Sie in unserem Leitfaden zu Supabase Auth.

Sicherheit: RLS gegen Security Rules

Bei beiden Systemen spricht der Browser direkt mit der Datenbank, also hängen beide von serverseitigen Regeln ab, die verhindern, dass ein Nutzer die Daten eines anderen sieht. Diese Regeln sind nicht optional.

Supabase nutzt PostgreSQL Row Level Security. Eine Policy an einer Tabelle wirkt wie eine zusätzliche WHERE-Bedingung bei jeder Abfrage, zum Beispiel „ein Nutzer darf Zeilen lesen, deren user_id seiner eigenen ID entspricht“. Laut Supabase-Dokumentation ist RLS nicht standardmäßig aktiv: Sie aktivieren es pro Tabelle, und der Service-Role-Key umgeht es, weshalb er auf dem Server bleiben muss. Eine Tabelle ohne RLS und mit Standardrechten kann für jeden lesbar sein, der den öffentlichen Schlüssel besitzt. Das ist der häufigste Fehler in generierten Apps.

Firebase nutzt Security Rules, eine eigene Sprache aus match- und allow-Anweisungen, die bei jeder Client-Anfrage geprüft werden. Server-Bibliotheken umgehen sie und unterliegen stattdessen Google Cloud IAM. Firebase dokumentiert eine einfache „allow everything“-Regel und warnt davor, sie je in Produktion zu verwenden. Sie stehen zu lassen ist die Firebase-Variante desselben Fehlers.

Ein praktischer Vorteil für Supabase: Policies sind einfaches SQL, und KI-Modelle schreiben gutes SQL. Die Firebase-Regelsprache ist kleiner und in den Trainingsdaten weniger vertreten. Das ist eine Beobachtung zum Werkzeug, keine Garantie in die eine oder andere Richtung.

Speicher und Serverfunktionen

Beide bieten Dateispeicher und Serverfunktionen. Der wichtigste Unterschied ist, was der Gratis-Tarif enthält. Supabase Storage gehört zum Free-Tarif (1 GB). Bei Firebase sind Cloud Storage und Cloud Functions im Spark-Tarif als nicht verfügbar gekennzeichnet, eine Web-App mit Uploads oder einem serverseitigen Geheimnis muss also auf Blaze wechseln.

Serverfunktionen brauchen Sie, sobald Sie einen Dienst mit geheimem Schlüssel aufrufen: Zahlungen, E-Mail, ein KI-Modell. Supabase nennt sie Edge Functions, mit 500.000 Aufrufen im Free-Tarif und 2 Millionen im Pro-Tarif. Cloud Functions for Firebase führen JavaScript, TypeScript oder Python aus und lassen sich durch Ereignisse von Firestore, Auth oder Storage, durch HTTPS-Aufrufe oder per Zeitplan auslösen, mit 2 Millionen kostenlosen Aufrufen im Monat auf Blaze. Firebase hat die reichere Auswahl an Ereignis-Triggern, Supabase das einfachere Denkmodell.

Gratis-Tarife und was Bezahlen kostet

Supabase berechnet einen planbaren Monatspreis, Firebase berechnet die Nutzung, die Rechnung folgt also dem Traffic. Die folgenden Zahlen wurden im November 2026 auf supabase.com/pricing und firebase.google.com/pricing geprüft.

Zwei Folgen. Erstens pausiert Supabase Free ein Projekt nach einer Woche ohne Aktivität. Für einen Prototyp ist das in Ordnung, für ein Produkt im Betrieb nicht, echte Apps gehören also auf Pro. Zweitens rechnet Firestore pro gelesenem und geschriebenem Dokument ab: Ein Screen, der 200 Dokumente lädt, kostet jedes Mal 200 Lesevorgänge, und ein Fehler, der eine Abfrage in einer Schleife ausführt, kann auf Blaze eine hohe Rechnung verursachen. Das Modell von Supabase ähnelt eher einer Pauschale mit Nutzungsgrenzen. Pro enthält Limits (zum Beispiel 250 GB Egress), über denen zusätzliche Nutzung berechnet wird. Die aktuellen Überschreitungspreise stehen auf der Preisseite.

Lock-in und Selbst-Hosting

Supabase lässt sich selbst hosten und basiert auf Standard-PostgreSQL, ein Ausstieg kostet also einen Datenbank-Dump. Wer Firebase verlässt, muss seine Datenschicht neu schreiben. Supabase dokumentiert einen Docker-basierten Weg zum Selbst-Hosting. Auch wenn Sie nie selbst hosten, liegen Ihre Daten in einer Postgres-Datenbank, die jeder Host betreiben kann.

Firebase ist ein Google-Dienst mit eigenen SDKs, eigenem Abfragemodell und eigener Regelsprache. Der Weg weg von Firestore bedeutet, das Schema in Tabellen umzubauen und jede Abfrage neu zu schreiben. Das ist ein normaler Preis für ein verwaltetes Produkt, und die Infrastruktur von Google ist eine echte Stärke, aber Sie sollten ihn einrechnen. Der Lock-in hängt auch davon ab, wem das Projekt gehört: Unser Artikel zu Supabase als Backend für KI-Baukästen erklärt die Frage eigenes Projekt gegen plattformverwaltetes Projekt.

Warum KI-App-Baukästen meist Supabase wählen

KI-Baukästen bevorzugen Supabase, weil ein Sprachmodell SQL-Schemata und Policies schreiben kann und ein Entwickler das Ergebnis später in einem Standardwerkzeug öffnen kann. Das ist eine begründete Vermutung über die Anreize, keine Aussage eines Anbieters. Dokumentiert ist: Das integrierte Backend von Lovable basiert auf dem Open-Source-Fundament von Supabase, und Lovable lässt Sie auch ein eigenes Supabase-Projekt verbinden.

Auch Cadrant, unser Baukasten, nutzt Supabase: Er generiert React-Web-Apps auf einem Supabase-Projekt in Ihrem eigenen Konto, wobei die KI die Migrationen und die RLS-Policies schreibt. Wir haben uns aus den oben genannten Gründen dafür entschieden, und es hat einen Preis, den wir in Kauf nehmen: Sie arbeiten mit SQL-Konzepten und mit einer Supabase-Rechnung, die getrennt von unserer läuft. Wenn Ihr Team schon tief in Firebase steckt oder Sie Offline-first-Synchronisierung auf dem Smartphone brauchen, hilft Ihnen ein KI-Baukasten auf Supabase nicht weiter. Vergleichen Sie Werkzeuge in unserem Leitfaden zu den besten KI-App-Buildern, und lesen Sie in unserer Dokumentation zur Supabase-Verbindung, wie die Anbindung funktioniert.

Was für welchen Fall

Entscheiden Sie nach der Form Ihrer Daten und Ihrem Ausstiegsplan, nicht nach dem Logo.

Wenn Sie noch ein Werkzeug suchen, um die App selbst zu bauen, zeigt die Seite zum Cadrant-Web-App-Baukasten, was die KI auf einem Supabase-Backend generiert.