Kurzfassung: Supabase und Firebase sind Backend-as-a-Service: sie bieten Postgres + Login + Realtime als Dienste, aber Ihr baut das Datenmodell, die Mandantentrennung, das Änderungsprotokoll. Kumiko ist Backend-als-generierter-Code: KI baut das alles, Ihr editiert und besitzt es.
Was Supabase / Firebase sind
Supabase: Open-Source-Backend-Stack auf Postgres-Basis. Login, Realtime, Storage, Edge-Functions als Dienste. Ihr schreibt SQL und Row-Level-Security-Policies, Supabase hostet das.
Firebase (Google): NoSQL-DB (Firestore), Login, Realtime, Functions. Älter, stärker auf Mobile fokussiert.
Beide sind enorm beliebt im Indie-Hacker- und Startup-Markt: schnell zu starten, viel Doku, große Community.
Wo sie stärker sind
- Reife und Doku: 5–10 Jahre alt, riesige Community, Stack Overflow voller Antworten
- Login von Haus aus: Magic Links, OAuth-Provider, MFA, alles fertig
- Edge-Functions: Deploy auf Edge in Sekunden (Supabase via Deno, Firebase via Cloud Functions)
- Mobile-SDKs: Firebase hat exzellente iOS- und Android-SDKs
- Free-Tier: beide haben sehr großzügige Free-Tiers für MVPs
Wo Kumiko stärker ist
| Aspekt | Supabase / Firebase | Kumiko |
|---|---|---|
| Zeit bis zur laufenden App | DB ist in Minuten da, aber ihr baut Login-Verkabelung, RLS, Frontend, Audit selbst | Unter 2 Minuten von Klick zu Live-URL: Login, Multi-Tenant, Audit, Realtime, Frontend inklusive |
| Mandantentrennung | Möglich, aber ihr schreibt RLS-Policies pro Tabelle und prüft selbst auf Lücken | Eingebaut, jede Entität ist tenant-scoped, Cross-Tenant-Zugriff ist explizit |
| Änderungsprotokoll | Selbst bauen (Trigger oder eigene Tabelle) | Eingebaut |
| Schema-Generierung | SQL schreiben | KI generiert aus Klartext-Beschreibung (ab H2 2026) |
| Workflows / State Machines | Edge-Functions hand-rollen | Framework-Bausteine |
| DACH/EU-Hosting | Supabase EU-Region möglich, Firebase US-Cloud-Default | On-Prem / Hetzner / Bare-Metal Default |
| Vendor-Lock-in | Supabase mittel (OSS, aber Hosting-Stack groß), Firebase hoch | Niedrig, generierter Code in eurem Repo, Framework öffentlich unter BSL |
| AI-Builder | Nein | Ja, Kern-Feature ab H2 2026 |
„Backend-as-a-Service” vs „komplette App in 2 Minuten”
Supabase und Firebase liefern euch die Teile: eine Datenbank, einen Login-Service, einen Realtime-Channel, Edge-Functions. Sie zu einem funktionierenden internen Tool zusammenzubauen ist euer Job: Schema-Design, RLS-Policies, eine Audit-Tabelle, ein Frontend das mit allem redet, Mandantentrennung wenn ihr sie braucht, manchmal eine State-Machine.
Kumiko liefert euch die zusammengebaute App. Klick neue App, Name vergeben, ihr bekommt Datenbank, Login, Mandanten-Scoping, Audit-Trail, Suche, Realtime, Datei-Storage und ein Frontend: alles verkabelt, alles unter einer URL, in unter 2 Minuten. Von dort baut ihr was euer Tool zu eurem macht, nicht was jedes interne Tool sowieso braucht.
Für einen Indie-Hacker beim zehnten Side-Projekt ist der Unterschied: Supabase erspart euch „ich will Postgres nicht selbst hosten”; Kumiko erspart euch „ich will nicht zum zehnten Mal dieselben fünf Services zusammenbauen”.
Wann Ihr Supabase wählen solltet
- Ihr baut ein MVP oder Side-Project und braucht keine Mandantentrennung
- Euer Team ist SQL-erfahren, RLS-Policies sind kein Problem
- OAuth-Provider (Google, GitHub, …) ist Hauptanforderung
- Edge-Functions / Edge-Compute ist Architektur-Anforderung
- Ihr mögt den Deno/PostgREST-Stack und arbeitet gerne Postgres-nah
Wann Ihr Firebase wählen solltet
- Mobile-First (iOS- und Android-Apps mit Realtime-Sync)
- Ihr wollt bewusst NoSQL (kein festes Schema, dynamische Strukturen)
- Google-Cloud-Stack ist sowieso schon im Einsatz
Wann Ihr Kumiko wählen solltet
- Ihr baut eine B2B-SaaS mit mehreren Mandanten ab Tag 1
- Änderungsprotokoll ist Compliance-Pflicht (HIPAA, SOC 2, ISO 27001, DSGVO)
- Euer Datenmodell ist komplex (Aggregate, State Machines, komplexe Beziehungen)
- Ihr wollt KI-Generierung des Backends, nicht nur Code-Vervollständigung
- DACH/EU-Hosting ist hart verlangt
Migration von Supabase nach Kumiko
Realistisch ein paar Tage für ein typisches Schema. Postgres bleibt (Eure Daten könnt Ihr behalten), Login wird neu (Kumiko hat ein eigenes Auth-Bundle), Edge-Functions werden zu TypeScript-Handlern. RLS-Policies werden zu Kumikos eingebauter Mandantentrennung und Field-Access.
Pilot-Programm: Zur Startseite ← Zurück zur Vergleichs-Übersicht