Serverpod vs Supabase vs Firebase: Dart-Backend im Vergleich

Du baust eine Flutter App und brauchst ein Backend. Drei Namen fallen immer: Serverpod, Supabase, Firebase. Alle drei funktionieren mit Flutter. Aber welches passt zu deinem Projekt?

Ich nutze alle drei in echten Projekten. Serverpod ist mein Hauptstack, Firebase läuft in fast jeder meiner Apps für Push Notifications und Crashlytics, und Supabase setze ich ein, wenn Kunden eine schnelle SQL-basierte Lösung wollen. Die Frage "welches Backend?" bekomme ich in Erstgesprächen so oft, dass ich die Antwort mal aufschreiben wollte.

Kurz zusammengefasst

• Serverpod ist ideal, wenn du Full-Stack Dart willst, eine Sprache, geteilte Typen, maximale Kontrolle
• Supabase passt am besten zu SQL-affinen Entwicklern, die Open Source und Self-Hosting wollen
• Firebase ist nach wie vor am schnellsten beim Prototyping und hat die ausgereifteste Flutter-Integration (FlutterFire)
• Alle drei haben ein kostenloses Free Tier, die Kosten unterscheiden sich aber massiv ab 5.000+ Nutzern
• Es gibt kein "bestes" Backend, es kommt auf Teamgröße, Projektphase und Langzeitstrategie an

Die drei Kandidaten im Überblick

Serverpod

Serverpod ist ein Open-Source Backend-Framework, komplett in Dart geschrieben. Version 2.x setzt auf PostgreSQL als Datenbank und generiert typsichere Client-Bibliotheken automatisch. Du definierst dein Datenmodell einmal und nutzt es in Flutter und auf dem Server. Kein JSON parsen, keine manuellen API-Contracts.

Supabase

Supabase ist die Open-Source Alternative zu Firebase. Unter der Haube steckt PostgreSQL mit Row-Level Security, Realtime-Subscriptions, Edge Functions und einem wachsenden Flutter SDK (supabase_flutter). Du kannst Supabase in der Cloud nutzen oder komplett self-hosten.

Firebase

Firebase ist Googles Backend-as-a-Service Plattform. NoSQL-Datenbank (Firestore), Cloud Functions, Authentication und das beste Flutter SDK am Markt (FlutterFire). Kein Server aufsetzen, kein DevOps, einfach loslegen. Mehr dazu in meinem ausführlichen Firebase-Artikel.

Sprache & Typsicherheit

Serverpod: Dart überall

Das ist der größte Vorteil von Serverpod. Du schreibst Frontend und Backend in Dart. Dein Datenmodell wird einmal definiert, und der Code-Generator erzeugt typsichere Klassen für Client und Server. Ändert sich ein Feld, schlägt der Compiler auf beiden Seiten an. Keine Runtime-Fehler wegen falscher JSON-Keys.

Für mich als Full-Stack Dart Entwickler ist das der Grund, warum ich Serverpod bevorzuge. Kein Context-Switching, keine doppelte Arbeit.

Supabase: SQL + Dart SDK

Bei Supabase schreibst du Backend-Logik in SQL (Row-Level Security Policies, Database Functions) oder in TypeScript/Deno (Edge Functions). Das Flutter SDK (supabase_flutter) ist in Dart geschrieben und wird aktiv entwickelt, ist aber nicht so ausgereift wie FlutterFire. Du arbeitest mit zwei Sprachen, Dart im Frontend, SQL/TypeScript im Backend.

Firebase: JavaScript/Python Backend, Dart Frontend

Cloud Functions schreibst du in Node.js oder Python. Dein Flutter-Code kommuniziert über das FlutterFire SDK. Die Typen sind nicht geteilt, du definierst dein Datenmodell einmal in Firestore und einmal in Dart. Das funktioniert, aber Änderungen musst du manuell synchron halten.

Wenn dein Team bereits Dart kann, ist Serverpod hier klar vorne. Eine Sprache, geteilte Typen, Compiler-Sicherheit.

Datenbank & Queries

Serverpod: PostgreSQL mit ORM

Serverpod nutzt PostgreSQL und bringt ein eigenes ORM mit. Du schreibst typsichere Queries in Dart, inklusive JOINs, Filterung, Sortierung und Pagination. Für komplexe Abfragen kannst du auch Raw SQL schreiben.

Supabase: PostgreSQL pur

Supabase ist im Kern eine PostgreSQL-Datenbank mit einer REST- und Realtime-API darüber. Du hast die volle Macht von SQL: JOINs, Views, Stored Procedures, Aggregationen. Row-Level Security sorgt dafür, dass Nutzer nur ihre eigenen Daten sehen. Wenn du SQL liebst, fühlt sich Supabase wie zu Hause an.

Firebase: Firestore (NoSQL)

Firestore ist eine dokumentenbasierte NoSQL-Datenbank. Für einfache CRUD-Operationen ist sie perfekt. Aber: Keine JOINs, keine komplexen WHERE-Klauseln, keine serverseitigen Aggregationen ohne Cloud Functions. Relationale Daten musst du denormalisieren. Das funktioniert, führt aber bei wachsender Komplexität zu Kopfschmerzen. Ich habe das in meinem Firebase-Artikel ausführlich beschrieben.

Für reine Query-Power gewinnt Supabase. Serverpod nutzt ebenfalls PostgreSQL, aber Supabase gibt dir direkteren Zugriff, du schreibst SQL, nicht ORM-Abstraktionen.

Echtzeit-Features

Serverpod: WebSockets eingebaut

Serverpod hat WebSocket-Support eingebaut. Du kannst Echtzeit-Kommunikation direkt in Dart implementieren, mit geteilten Typen. Für Chat-Features, Live-Updates oder Multiplayer-Logik funktioniert das gut.

Supabase: Realtime-Subscriptions

Supabase Realtime lauscht auf Datenbank-Änderungen und pusht sie an alle verbundenen Clients. Du abonnierst eine Tabelle, und jede INSERT/UPDATE/DELETE-Operation kommt sofort an. Das Setup ist minimal, ein paar Zeilen Code im Flutter SDK.

Firebase: Firestore Snapshots

Hier spielt Firebase seine größte Stärke aus. Echtzeit-Sync ist in Firestore nativ eingebaut. Ein Snapshot-Listener auf einer Collection und deine UI aktualisiert sich automatisch bei jeder Änderung. Das ist seit Jahren battle-tested und funktioniert zuverlässig. Für reine Echtzeit-Apps ist das nach wie vor die einfachste Lösung.

Echtzeit ist Firestores DNA, da kommt so schnell nichts ran. Supabase Realtime funktioniert gut, Serverpod gibt dir mehr Kontrolle. Aber für den einfachsten Einstieg: Firebase.

Authentifizierung

Serverpod: Modul-basiert

Serverpod bringt ein Auth-Modul mit, das Google, Apple und E-Mail/Passwort unterstützt. Es funktioniert, ist aber nicht so umfangreich wie die Alternativen. Für spezielle Anforderungen baust du die Auth-Logik selbst, was bei einem eigenen Backend aber ohnehin normal ist.

Supabase: GoTrue Auth

Supabase Auth basiert auf GoTrue und unterstützt OAuth (Google, Apple, GitHub, etc.), Magic Links, E-Mail/Passwort und Phone Auth. Row-Level Security Policies greifen direkt auf den Auth-Status zu, du schreibst also weniger Backend-Code für Berechtigungen.

Firebase: Firebase Auth

Firebase Authentication hat jeden Login-Provider, den du brauchst. Token-Management, Passwort-Reset, Account-Linking, Multi-Factor Auth, alles out of the box. FlutterFire macht die Integration trivial.

Bei Auth führt kein Weg an Firebase vorbei, wenn du die volle Bandbreite willst. Supabase kommt mit GoTrue aber nah ran, und hat den Vorteil, dass RLS-Policies direkt auf den Auth-Status zugreifen.

Hosting & Infrastruktur

Serverpod: Eigenes Hosting

Serverpod läuft auf deinem eigenen Server. VPS, Cloud VM, Kubernetes, du entscheidest. Das bedeutet mehr Kontrolle, aber auch mehr Verantwortung. Du musst dich um Deployment, Skalierung und Monitoring kümmern. In meinen Projekten läuft Serverpod auf Kubernetes, wie ich in meinem Production-Backend Artikel beschrieben habe.

Supabase: Cloud oder Self-Hosted

Supabase bietet Managed Hosting in der Cloud und die Möglichkeit, alles selbst zu hosten (Docker Compose). Das ist ein großer Vorteil: Du startest in der Cloud und migrierst später auf eigene Infrastruktur, wenn du willst. Kein Vendor Lock-in.

Firebase: Google Cloud

Firebase läuft auf Googles Infrastruktur. Automatische Skalierung, globale Verfügbarkeit, null DevOps. Aber: Du bist an Google gebunden. Eine Migration weg von Firebase ist aufwändig, deine Security Rules, Cloud Functions und Firestore-Struktur sind proprietär.

Supabase hat hier die flexibelste Position: Managed Cloud zum Starten, Self-Hosting wenn du es brauchst. Serverpod gibt dir die meiste Kontrolle, Firebase die wenigste Arbeit.

Kosten

Die Kostenfrage wird oft unterschätzt. Hier ein realistischer Vergleich für verschiedene App-Größen:

Wichtig: Bei Serverpod zahlst du für die Infrastruktur (Server, Datenbank), nicht für das Framework selbst. Die Kosten sind vorhersagbar. Bei Firebase können schlecht optimierte Listener die Kosten sprengen, ich habe das mehrfach erlebt. Supabase liegt preislich dazwischen und bietet mit dem Pro Plan (25 USD/Monat) ein gutes Paket für die meisten Apps.

Wer die laufenden Kosten einer App langfristig kalkulieren will, sollte sich die Preismodelle genau anschauen. Die Gesamtkosten einer App-Entwicklung gehen weit über das Backend hinaus.

Langfristig ist Serverpod am günstigsten, weil du nur Infrastruktur zahlst, keine Plattform-Gebühr. Supabase hat das fairste Pay-as-you-grow Modell. Firebase ist am Anfang kostenlos, kann aber bei Wachstum überraschen.

Flutter-Integration

Serverpod

// Typsicherer Methodenaufruf, kein JSON, kein Parsing
final user = await client.users.getUser(userId);
print(user.name); // Compiler kennt den Typ

Du rufst Methoden auf, nicht HTTP-Endpoints. Der generierte Client ist typsicher. Ändert sich das Datenmodell, merkst du es beim Kompilieren, nicht erst zur Laufzeit.

Supabase

// SQL-ähnliche Syntax im Dart SDK
final response = await supabase
    .from('users')
    .select('id, name, email')
    .eq('id', userId)
    .single();
final name = response['name'] as String;

Das supabase_flutter SDK funktioniert gut, aber du arbeitest mit Maps und Strings. Keine geteilten Typen, kein Compiler-Check auf Feldnamen. Du kannst das mit Code-Generierung verbessern, aber out-of-the-box ist es nicht typsicher.

Firebase

// Firestore Dokument lesen
final doc = await FirebaseFirestore.instance
    .collection('users')
    .doc(userId)
    .get();
final name = doc.data()?['name'] as String?;

FlutterFire ist das ausgereifteste SDK der drei. Die Integration fühlt sich nativ an, die Doku ist sehr gut. Aber auch hier: keine geteilten Typen. Du arbeitest mit Maps und castest manuell.

Für Typsicherheit gewinnt Serverpod. Für SDK-Reife und Dokumentation Firebase. Supabase liegt dazwischen.

Ökosystem & Community

Serverpod hat das kleinste Ökosystem der drei. Das ist kein Geheimnis. Die Community wächst, aber wenn du um 2 Uhr nachts ein obskures Problem googelst, findest du für Firebase 50 Antworten und für Serverpod vielleicht 2. Für mich überwiegen die Vorteile trotzdem, aber das muss man ehrlich sagen.

Zehn Jahre Vorsprung sind zehn Jahre Vorsprung. Supabase holt schnell auf. Serverpod ist das Nesthäkchen, das erst noch wachsen muss.

Vergleichstabelle: Alles auf einen Blick

Wann welches Backend?

Serverpod wählen wenn:

• Du bereits Dart/Flutter kannst und Full-Stack Dart willst
• Du ein eigenes Backend mit voller Kontrolle brauchst
• Typsicherheit zwischen Client und Server für dich Priorität hat
• Du langfristig planst und kalkulierbare Kosten willst
• Dein Team klein ist und eine Sprache alles einfacher macht

Supabase wählen wenn:

• Du SQL-affin bist und relationale Daten hast
• Du Open Source und die Option auf Self-Hosting schätzt
• Du schnell starten willst, aber keinen Vendor Lock-in akzeptierst
• Row-Level Security für dein Berechtigungsmodell Sinn macht

Firebase wählen wenn:

• Du ein MVP oder Prototyp so schnell wie möglich brauchst
• Echtzeit-Features (Chat, Kollaboration) im Mittelpunkt stehen
• Du als Solo-Entwickler kein Backend-Setup willst
• Dein Projekt überschaubar bleibt und du die FlutterFire-Integration nutzen willst

Keines der drei wenn:

• Du bereits ein großes Team mit Node.js/Python/Go-Expertise hast, dann nutze, was dein Team kennt
• Du eine reine Website baust, nimm Nuxt, Astro oder Next.js

Mein persönliches Setup

In der Praxis nutze ich nicht nur eins, sondern kombiniere:

Serverpod ist mein Haupt-Backend. Die Business-Logik, Datenbankanbindung, API-Endpoints, alles läuft in Dart. Geteilte Typen zwischen Flutter und Server sparen mir Stunden an Debugging-Zeit. Das Backend läuft auf Kubernetes für automatische Skalierung.

Firebase nutze ich ergänzend, und zwar für das, was es am besten kann:

• Cloud Messaging für Push Notifications auf iOS und Android
• Crashlytics für Echtzeit-Absturzberichte
• Remote Config für Feature Flags ohne App Store Update
• Auth in Projekten, bei denen ich schnell starten will

Supabase setze ich ein, wenn ein Kunde explizit eine SQL-basierte Lösung will oder wenn Self-Hosting eine Anforderung ist.

Die Kombination klingt aufwändig, ist es aber nicht. Firebase kümmert sich um die Infrastruktur-Services (Push, Crashes), Serverpod um die Kernlogik. Jeder Service macht das, was er am besten kann.

Falls dich interessiert, wie die Kommunikation zwischen App und Backend funktioniert oder wie eine Production-Architektur im Detail aussieht, habe ich dazu eigene Artikel geschrieben.

Häufig gestellte Fragen