Where Firebase fits — and where teams hit the wall
Where Firebase fits well: mobile and web teams who want auth, a document database, hosting, and analytics from one Google console, working today rather than next sprint.
Where teams outgrow Firebase: when the document model and read-based pricing begin dictating the data design, server logic exists only as Google Cloud Functions, and leaving means exporting everything out of Google’s shapes first.
Fast to start, Google-shaped to keep
Firebase’s speed is real: authentication, Firestore, storage, and hosting arrive as one SDK and one console. The price of that speed is shape — your data becomes documents and subcollections, your queries become the ones Firestore allows, and your bill becomes a function of reads you have to design around.
Server logic deepens the tie. Cloud Functions live in Google Cloud, so the backend’s second half sits in a second console with its own IAM and pricing, and neither half can be declared, diffed, or reviewed as one system.
The same backend as a declared project
On KERNSTACK the backend is resources in one stack.json: functions for request logic, workers for anything long, tables for records, buckets for uploads, and a search index when lists stop being enough.
- Gateway routes guard the API surface of the project; keys stay inside it
- Workflows add ordered steps and human approvals without a second cloud console
- The project runs in one European zone on our own bare metal, not in a rented region
Side-by-Side: Firebase vs KERNSTACK
| Dimension | Firebase | KERNSTACK (Software Lifecycle Cloud) |
|---|---|---|
| Data model | Firestore documents, subcollections, and query limits | Key-value tables designed around your access keys |
| Server logic | Cloud Functions inside Google Cloud | Functions and container workers in the same project |
| Unit of change | Console configuration across Firebase and Google Cloud | One stack.json, reviewed as a plan diff |
| Pricing shape | Per-read, per-write, and per-service meters | One credit balance; compute at 0.01 credits per GiB-second |
| Operator | Google, in Google regions | Our own bare metal in Europe |
| Agents | External tools holding Google credentials | Agents draft in sandboxes; people approve before production |
Frequently asked questions
Through Firestore’s export tooling, as JSON-shaped documents, then reshaped to the keys your KERNSTACK tables declare. It is a transformation, not a copy — document hierarchies flatten into keyed records — and planning that reshape is the real migration work.
Authentication is re-declared at the project gateway rather than imported, and that deserves honesty: password hashes do not export from Firebase Auth, so user accounts are the piece to plan explicitly — typically a re-login or reset flow at cutover.
For a first mobile backend in an afternoon, Firebase is hard to beat, and pretending otherwise would be dishonest. KERNSTACK pays off a little later: when the backend needs workers, workflows, search, and agent-made changes that a person reviews as one project.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.