Wer heute eine Web-App oder ein MVP schnell auf die Beine stellen möchte, stößt unweigerlich auf die Frage: Soll ich ein eigenes Backend bauen, oder nutze ich eine Backend-as-a-Service-Plattform (BaaS)? Mit Firebase, Supabase und Pocketbase gibt es drei Kandidaten mit sehr unterschiedlichen Philosophien – vom vollständig gemanagte Cloud-Service bis zur winzigen Go-Binary, die auf einem Raspberry Pi läuft. In diesem Artikel vergleiche ich alle drei ehrlich und zeige, wann welche Plattform die bessere Wahl ist.
Was ist Backend-as-a-Service (BaaS)?
Backend-as-a-Service-Plattformen nehmen dir den Aufbau und die Wartung eines Backends ab: Datenbank, Authentifizierung, Datei-Upload, Echtzeit-Subscriptions, API-Generierung – das alles bekommst du als fertige Infrastruktur. Du fokussierst dich auf das Frontend und deine Business-Logik, nicht auf Datenbankschemas, Auth-Flows und Deployment-Pipelines.
Das klingt verlockend, hat aber einen Preis: Entweder zahlst du mit echtem Geld (für gemanagte Cloud-Services wie Firebase), oder du zahlst mit Betriebsaufwand (Self-Hosted wie Supabase oder Pocketbase). Und nicht zu vergessen: Vendor Lock-in. Wer tief in ein BaaS-Ökosystem einsteigt, hat es später schwer, wieder herauszukommen.
Firebase – das Urgestein der Cloud-BaaS
Firebase ist das älteste und bekannteste der drei und gehört seit 2014 zu Google. Es bietet ein vollständiges Ökosystem: Firestore (NoSQL-Datenbank), Firebase Auth, Cloud Functions, Firebase Hosting, Cloud Storage und vieles mehr. Die SDKs für Web, iOS und Android sind exzellent gepflegt und die Integration in Google Cloud ist nahtlos.
Der größte Vorteil von Firebase ist die Maturity: Millionen von Projekten weltweit laufen auf Firebase, die Dokumentation ist umfangreich und die Community ist groß. Für schnelle Prototypen und kleine Apps ist Firebase oft die einfachste Wahl – der Einstieg dauert Minuten.
Der größte Nachteil: Firebase ist stark proprietär. Firestore ist kein Standard-Datenbankformat, Cloud Functions sind an die Google-Infrastruktur gebunden, und das Pricing skaliert schlecht bei größeren Datenmengen. Wer aus Firebase herausmöchte, steht vor einer aufwändigen Migration. Außerdem: Du hast keine Kontrolle über deine Daten – sie liegen bei Google.
Firebase im Überblick
- Datenbank: Firestore (NoSQL, dokumentenbasiert) + Realtime Database (JSON-Baum)
- Auth: Email/Passwort, Social Login (Google, GitHub, etc.), Anonymous Auth
- Storage: Cloud Storage (Google Cloud Storage-kompatibel)
- Functions: Cloud Functions (Node.js, Python, Go)
- Pricing: Großzügiges Free Tier, dann nutzungsbasiert – kann teuer werden
- Self-Hosting: ❌ Nicht möglich
Supabase – die Open-Source-Firebase-Alternative
Supabase wurde 2020 gegründet mit einem klaren Versprechen: "Firebase Alternative, but with PostgreSQL." Dahinter steckt ein beeindruckendes Open-Source-Stack: PostgreSQL als Datenbank, PostgREST für die automatische REST-API, GoTrue für Authentication, Realtime für Echtzeit-Subscriptions via Websockets, Storage für Dateien und Edge Functions (Deno) für Serverless-Code.
Was Supabase besonders macht: Du arbeitest mit echtem SQL. Wenn du PostgreSQL kannst, kannst du Supabase. Die Row-Level Security (RLS) von PostgreSQL ermöglicht feinkörnige Zugriffsregeln direkt in der Datenbank. Und da alles Standard-PostgreSQL ist, kannst du jederzeit auf eine eigene Datenbank migrieren – kein Vendor Lock-in auf Datenbankebene.
Supabase bietet einen gehosteten Cloud-Service (supabase.com) mit großzügigem Free Tier sowie Self-Hosting über Docker Compose oder Kubernetes. Das Selbst-Hosten ist realistisch, aber nicht trivial: Der Stack besteht aus mehreren Containern (PostgreSQL, PostgREST, GoTrue, Realtime, Storage, Proxy), und die Konfiguration ist komplex.
Supabase im Überblick
- Datenbank: PostgreSQL (vollständig, mit SQL, RLS, Extensions)
- Auth: Email/Passwort, Magic Links, Social Login, Phone Auth, SAML
- Storage: S3-kompatibel, mit CDN-Integration
- Functions: Edge Functions (Deno) für Serverless-Logik
- Pricing: Free Tier (2 Projekte), dann ab $25/Monat pro Projekt
- Self-Hosting: ✅ Möglich (Docker Compose, komplex)
Pocketbase – die Ein-Datei-Lösung für Self-Hoster
Pocketbase ist das Außenseiter-Projekt der drei: Eine einzelne Go-Binary, die einen vollständigen Backend-Stack mitbringt – Admin-UI, SQLite-Datenbank, Echtzeit-API, Auth und File Storage. Keine Container, keine separate Datenbank, keine Konfigurationsdateien. Einfach die Binary herunterladen, starten, fertig.
Der Ansatz ist radikal minimalistisch und gleichzeitig überraschend funktional. Pocketbase eignet sich hervorragend für kleine bis mittlere Anwendungen, Hobby-Projekte und interne Tools, wo du die volle Kontrolle über deine Daten willst, aber nicht das Gewicht eines vollständigen Backend-Stacks tragen möchtest.
Pocketbase skaliert nicht horizontal – es ist ein Single-Node-System. Das ist kein Bug, sondern eine Designentscheidung: Für die meisten Projekte reicht ein einzelner Server mit SQLite. Und wenn deine App wächst, kannst du zu Supabase oder einer eigenen PostgreSQL-Instanz migrieren – das API-Format ist ähnlich genug, um eine Migration zu erleichtern.
Pocketbase im Überblick
- Datenbank: SQLite (eingebettet, kein separater DB-Server)
- Auth: Email/Passwort, OAuth2 (Google, GitHub, GitLab, etc.), API-Keys
- Storage: Lokales Dateisystem (oder S3 via Plugin)
- Functions: JavaScript-Hooks für serverseitige Logik
- Pricing: Komplett kostenlos (Open Source, MIT)
- Self-Hosting: ✅ Extrem einfach (eine Binary!)
Vergleich: Wer gewinnt in welchem Bereich?
Schnelligkeit des Einstiegs
Hier gewinnt Firebase knapp vor Pocketbase. Firebase hat jahrelang seinen Onboarding-Flow perfektioniert, und Pocketbase ist mit einer einzigen Binary extrem schnell gestartet. Supabase liegt dahinter – zwar einfach für Cloud-Projekte, aber self-hosted ist die Konfiguration aufwändiger.
Datenkontrolle & Datenschutz
Klarer Gewinner: Pocketbase. Die Daten liegen auf deinem Server, in einer SQLite-Datei. Supabase self-hosted ist ebenfalls datensouverän, aber aufwändiger. Firebase: keine Kontrolle – die Daten sind bei Google.
SQL vs. NoSQL
Wenn du relationale Daten brauchst, ist Supabase der klare Gewinner. PostgreSQL mit vollständiger SQL-Unterstützung, JOINs, Transaktionen und Extensions. Pocketbase verwendet SQLite, das auch relational ist, aber weniger mächtig. Firebase ist NoSQL – für einfache Datenstrukturen gut, für komplexe Relationen schwierig.
Skalierbarkeit
Firebase skaliert theoretisch unbegrenzt (Google-Infrastruktur), praktisch aber teuer. Supabase skaliert gut auf einem dedizierten Server oder in Cloud-Umgebungen. Pocketbase skaliert vertikal (größerer Server), nicht horizontal – für die meisten Projekte völlig ausreichend.
Vendor Lock-in
Firebase: Sehr hohes Lock-in. Firestore ist proprietär, Cloud Functions laufen nur bei Google. Supabase: Niedriges Lock-in – PostgreSQL ist Standard, Daten sind portierbar. Pocketbase: Kein Lock-in – SQLite-Datei ist überall lesbar, und Pocketbase ist selbst Open Source.
Preisvergleich
| Platform | Free Tier | Paid Start | Self-Hosted |
|---|---|---|---|
| Firebase | Großzügig (mit Limits) | Pay-as-you-go | ❌ |
| Supabase | 2 Projekte, 500MB DB | $25/Monat/Projekt | ✅ Kostenlos |
| Pocketbase | Vollständig kostenlos | – | ✅ Kostenlos |
Docker-Setup: Supabase und Pocketbase im Vergleich
Pocketbase – das geht so einfach:
# Pocketbase starten – das war's
docker run -d \
--name pocketbase \
-p 8090:8090 \
-v pb_data:/pb/pb_data \
ghcr.io/muchobien/pocketbase:latest
# Admin-UI: http://localhost:8090/_/
Supabase – benötigt Docker Compose:
# Supabase self-hosted (stark vereinfacht)
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker
cp .env.example .env
# .env anpassen (JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, ...)
docker compose up -d
# Admin-UI: http://localhost:8000
# Studio: http://localhost:3000
Supabase self-hosted erfordert mindestens 8 GB RAM und mehrere Stunden Konfigurationsaufwand. Für einfache Projekte ist das oft überdimensioniert.
Wann welche Plattform wählen?
Firebase wählen, wenn…
- Du ein mobiles App-Projekt mit iOS/Android-Fokus hast
- Du bereits tief im Google Cloud Ökosystem verwurzelt bist
- Du schnell ein Proof-of-Concept brauchst und Vendor Lock-in akzeptierst
- Du Firebase Analytics, A/B Testing oder Crashlytics brauchst
Supabase wählen, wenn…
- Du relationale Daten und SQL brauchst
- Du PostgreSQL-Features (RLS, Extensions, Views) nutzen möchtest
- Du entweder Cloud-gehostet oder self-hosted starten möchtest
- Du auf Datensouveränität Wert legst und die Infrastruktur selbst kontrollieren möchtest
Pocketbase wählen, wenn…
- Du maximale Einfachheit willst – eine Binary, ein Server, eine Datei
- Du ein Hobby-Projekt, MVP oder internes Tool baust
- Deine App keine extreme Last bewältigen muss
- Du Kosten minimieren und volle Datenkontrolle behalten möchtest
Mein Fazit
Es gibt keine universell richtige Antwort – aber es gibt eine ehrliche Einschätzung:
Für neue Projekte mit Self-Hosting-Anspruch: Ich würde fast immer mit Pocketbase anfangen. Es ist das risikoärmste Experiment: In 10 Minuten läuft dein Backend, die Daten gehören dir, und wenn das Projekt wächst, migrierst du auf Supabase oder PostgreSQL. Der Migrations-Aufwand ist überschaubar.
Für ernsthafte Produktionsanwendungen mit komplexen Datenmodellen: Supabase – entweder als Cloud-Service oder self-hosted auf einem dedizierten Server. PostgreSQL ist der richtige Fundament für komplexe Daten, und das Supabase-Ökosystem ist gereift.
Firebase empfehle ich primär für mobile Apps in bestehenden Google-Ökosystemen oder wenn du explizit die Firebase-spezifischen Features (Google Analytics, A/B Testing) brauchst. Für neue Web-Projekte würde ich firebase heute nicht mehr wählen – der Vendor Lock-in ist zu hoch, und Supabase bietet die meisten Features mit offenerem Ökosystem.