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
Ehrlich:
- 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
Ehrlich:
- 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-Compliance ist hart verlangt (Schrems-II-konform)
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: ../story
← Zurück zur Vergleichs-Übersicht