--- title: "Serverpod vs Supabase vs Firebase: Dart-Backend im Vergleich" description: "Serverpod, Supabase oder Firebase als Flutter Backend? Ehrlicher Vergleich mit Kosten, Code-Beispielen und klarer Empfehlung vom Full-Stack Dart Entwickler." canonical_url: "https://robocitrus.com/blog/serverpod-vs-supabase-vs-firebase" last_updated: "2026-07-19T00:13:04.836Z" --- 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](https://serverpod.dev) 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](https://supabase.com) 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](https://firebase.google.com) 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](/blog/firebase-backend). --- ## 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](/blog/warum-ich-flutter-liebe) 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](/blog/firebase-backend) 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](/blog/so-funktioniert-das-backend-meiner-production-app) 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:
Szenario Serverpod Supabase Firebase
MVP, 100 Nutzer 5-15 EUR (VPS) 0 EUR (Free Tier) 0 EUR (Spark Plan)
Kleine App, 1.000 Nutzer 15-30 EUR (VPS) 0-25 EUR (Free/Pro) 5-20 EUR (Blaze)
Mittlere App, 5.000 Nutzer 30-80 EUR (VPS/Cloud) 25-75 EUR (Pro) 30-150 EUR (Blaze)
Wachsende App, 10.000 Nutzer 50-150 EUR (Cloud) 75-150 EUR (Pro/Team) 80-400 EUR (Blaze)
Große App, 50.000 Nutzer 150-400 EUR (Kubernetes) 150-400 EUR (Team) 300-1.500+ EUR (Blaze)
**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](/blog/laufende-app-kosten) langfristig kalkulieren will, sollte sich die Preismodelle genau anschauen. Die [Gesamtkosten einer App-Entwicklung](/blog/app-entwicklung-kosten-2026) 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 ```dart // 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 ```dart // 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 ```dart // 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
Kriterium Serverpod Supabase Firebase
GitHub Stars ~2.500 ~75.000 n/a (Google)
Alter seit 2022 seit 2020 seit 2014
Stack Overflow Antworten wenige wachsend sehr viele
Flutter SDK Reife gut (eigenes Framework) gut (supabase_flutter) exzellent (FlutterFire)
Dokumentation solide sehr gut exzellent
Open Source ja ja teilweise
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
Kriterium Serverpod Supabase Firebase
Sprache Backend Dart SQL / TypeScript JavaScript / Python
Sprache Frontend Dart Dart Dart
Datenbank PostgreSQL PostgreSQL Firestore (NoSQL)
Typsicherheit geteilte Typen manuell manuell
Echtzeit WebSockets Realtime Subscriptions Firestore Snapshots
Auth Modul (Google, Apple, E-Mail) GoTrue (viele Provider) Firebase Auth (alle Provider)
Hosting Self-Hosted Cloud oder Self-Hosted Google Cloud (managed)
Open Source ja ja teilweise
Vendor Lock-in keiner gering hoch
Kosten (10k Nutzer) 50-150 EUR 75-150 EUR 80-400 EUR
Flutter SDK typsicher, generiert funktional, Maps ausgereift, Maps
Community klein groß sehr groß
Lernkurve mittel (Dart-Kenntnisse nötig) mittel (SQL-Kenntnisse hilfreich) niedrig
--- ## 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](/blog/rest-vs-graphql) funktioniert oder wie eine [Production-Architektur](/blog/so-funktioniert-das-backend-meiner-production-app) im Detail aussieht, habe ich dazu eigene Artikel geschrieben. --- ## Häufig gestellte Fragen Ja, und ich mache genau das in meinen Production Apps. Serverpod übernimmt die Hauptlogik und Datenbank, Firebase liefert Push Notifications (Cloud Messaging), Crashlytics und Remote Config. Die beiden Systeme stehen sich nicht im Weg. Du nutzt einfach beide SDKs in deiner Flutter App. Ja und nein. Supabase ersetzt Firebase nicht 1:1, sondern verfolgt einen anderen Ansatz. Die größten Unterschiede: Supabase nutzt PostgreSQL (relational) statt Firestore (NoSQL), ist vollständig Open Source und bietet Self-Hosting. Für Authentifizierung und Echtzeit-Features ist Supabase eine echte Alternative. Für Crashlytics und Push Notifications brauchst du weiterhin Firebase oder eine andere Lösung. Wenn du bereits Dart und Flutter kannst, ist der Einstieg in Serverpod überschaubar. Du lernst, wie du Endpoints definierst, Datenmodelle erstellst und den Code-Generator nutzt. In ein bis zwei Tagen hast du ein funktionierendes Setup. Die Herausforderung liegt eher im Hosting und DevOps, du brauchst einen Server und musst dich um Deployment kümmern. Für kleine Projekte: Firebase (Spark Plan) und Supabase (Free Tier) kosten nichts. Für wachsende Apps ist Serverpod am günstigsten, weil du nur für die Infrastruktur zahlst und die Kosten linear steigen. Firebase kann bei schlecht optimierten Queries überraschend teuer werden. Eine ausführliche Kalkulation findest du in meinem Artikel über [laufende App-Kosten](/blog/laufende-app-kosten). Ja, aber es ist Aufwand. Firestore-Daten lassen sich exportieren, aber Security Rules, Cloud Functions und die gesamte Architektur sind Firebase-spezifisch. Mein Tipp: Wenn du von Anfang an weißt, dass du langfristig planst, starte direkt mit Serverpod oder Supabase. Falls du bereits auf Firebase sitzt, kapsle die Firebase-Logik hinter Abstraktionsschichten, damit ein späterer Wechsel einfacher wird. Wenn es nur um Geschwindigkeit geht: Firebase. Du hast in einem Tag ein funktionierendes Backend. Wenn du von Anfang an sauber bauen willst und Dart kannst: Serverpod, der Mehraufwand beim Setup zahlt sich nach wenigen Wochen aus. Wenn du SQL-Erfahrung hast und Vendor Lock-in vermeiden willst: Supabase. Alle drei sind valide, es hängt von deinem Team und deiner Langzeitstrategie ab. Mehr zum Thema MVP findest du in meinem [App-Entwicklung Kosten Artikel](/blog/app-entwicklung-kosten-2026).