Kumiko vs. Supabase / Firebase
TL;DR: Supabase and Firebase are backend-as-a-service: Postgres + auth + realtime as services, but you build the data model, the multi-tenant separation, the audit trail. Kumiko is backend-as-generated-code: AI builds it, you edit and own it.
What Supabase / Firebase are
Supabase: Open-source backend stack on Postgres. Auth, realtime, storage, edge functions as services. You write SQL and Row-Level-Security policies, Supabase hosts it.
Firebase (Google): NoSQL DB (Firestore), auth, realtime, functions. Older, more mobile-focused.
Both are massively popular in the indie-hacker and startup market: fast to start, lots of docs, big community.
Where they’re stronger
- Maturity and docs: 5 to 10 years old, huge community, Stack Overflow full of answers
- Auth out of the box: magic links, OAuth providers, MFA, all done
- Edge functions: deploy to the edge in seconds (Supabase via Deno, Firebase via Cloud Functions)
- Mobile SDKs: Firebase has excellent iOS and Android SDKs
- Free tier: both have very generous free tiers for MVPs
Where Kumiko is stronger
| Aspect | Supabase / Firebase | Kumiko |
|---|---|---|
| Time to running app | DB ready in minutes, but you still build auth wiring, RLS, frontend, audit | Under 2 minutes from click to live URL: auth, multi-tenant, audit, realtime, frontend included |
| Multi-tenant | Possible, but you write RLS policies per table and audit yourself | Built-in, every entity is tenant-scoped, cross-tenant access is explicit |
| Audit trail | Build it yourself (triggers or own table) | Built in |
| Schema generation | Write SQL | AI generates from plain-text description (H2 2026) |
| Workflows / state machines | Hand-roll edge functions | Framework primitives |
| EU hosting | Supabase EU region possible, Firebase US-cloud default | On-prem / Hetzner / bare-metal default |
| Vendor lock-in | Supabase medium (OSS but big hosting stack), Firebase high | Low, generated code in your repo, framework public under BSL |
| AI builder | No | Yes, core feature H2 2026 |
“Backend-as-a-service” vs “complete app in 2 minutes”
Supabase and Firebase give you the parts: a database, an auth service, a realtime channel, edge functions. Putting them together into a working internal tool is your job: schema design, RLS policies, an audit table, a frontend that talks to all of them, multi-tenant separation if you need it, sometimes a state machine.
Kumiko gives you the assembled app. Click new app, name it, you get a database, auth, multi-tenant scoping, audit trail, search, realtime, file storage, and a frontend: all wired up, all under one URL, in under 2 minutes. From there you build what makes your tool yours, not what every internal tool needs.
For an indie hacker shipping their tenth side project, the difference is: Supabase saves you “I don’t want to host Postgres myself”; Kumiko saves you “I don’t want to assemble the same five services for the tenth time”.
When you should pick Supabase
- You’re building an MVP or side project and don’t need multi-tenant
- Your team is SQL-fluent, RLS policies aren’t a problem
- OAuth providers (Google, GitHub, …) are a primary requirement
- Edge functions / edge compute is an architecture requirement
- You like the Deno/PostgREST stack and want to work close to Postgres
When you should pick Firebase
- Mobile-first (iOS and Android apps with realtime sync)
- You explicitly want NoSQL (no fixed schema, dynamic structures)
- Google Cloud stack is already in use anyway
When you should pick Kumiko
- You’re building a B2B SaaS with multiple tenants from day one
- Audit trail is compliance-required (HIPAA, SOC 2, ISO 27001, GDPR)
- Your data model is complex (aggregates, state machines, complex relations)
- You want AI generation of the backend, not just code completion
- EU hosting is a hard requirement
Migration from Supabase to Kumiko
Realistically a few days for a typical schema. Postgres stays (you keep your data), auth is replaced (Kumiko has its own auth bundle), edge functions become TypeScript handlers. RLS policies become Kumiko’s built-in tenant-scoping and field-access.
Pilot program: [email protected]