- Firebase is a fast way to launch; move only when it starts working against the product, the bill or a client requirement.
- Firestore bills per document read, write and delete, and live listeners are charged a read for each document that changes.
- Reports, joins and complex filters are where Firestore apps most often outgrow it.
- You rarely need to leave Firebase completely: many apps keep Authentication and Cloud Messaging and move only the data.
- Move in stages behind your own API, and remember that old app versions keep talking to Firestore until users update.
When should an app move off Firebase?
Move when Firebase starts working against the product: when reads and live listeners make the monthly bill hard to predict, when reports need joins and filters that Firestore does not support well, when business rules are spread across security rules and Cloud Functions, or when a client requires the data in your own database. If none of these apply, stay. When you do move, do it in stages: keep Firebase Authentication and Cloud Messaging at first, put your own API in front of the data, and migrate one area at a time.
Firebase is a good way to launch, and moving off it is a project, not a weekend. Our mobile app development team often keeps parts of Firebase in place long after the data has moved.
What are the signs an app has outgrown Firebase?
- The bill is hard to explain. Costs rise faster than users because screens read many documents or listen to large result sets.
- Reports are painful. Managers want totals by month, region and product, and each new report needs a new index, a new collection or an export.
- Queries hit limits. Firestore limits OR, in and array-contains-any queries to 30 disjunctions and not-in filters to 10 values, and combining equality and range filters needs a composite index (Firestore queries).
- Search needs more. Firestore's built-in text search requires an Enterprise edition database (Firestore text search), so many apps add a separate search service anyway.
- Logic is scattered. Rules about who can do what live partly in the app, partly in security rules and partly in functions, and nobody is sure which is the source of truth.
- A client or auditor asks where the data lives, who can reach it and how it is backed up, and the answers need to be in your own hands.
Why do Firestore bills grow in ways teams do not expect?
Cloud Firestore bills for the documents you read, write and delete, the index entries read by queries, storage and network traffic. The free quota is 50,000 reads, 20,000 writes and 20,000 deletes a day, plus 1 GiB of stored data, for one database per project. Every query costs at least one read, even when it returns nothing. Live listeners are charged a read each time a document in the result set is added or updated, and with offline persistence a listener that has been disconnected for more than 30 minutes is billed as a new query when it reconnects (Cloud Firestore pricing).
None of this is a reason to leave on its own. A dashboard that listens to a thousand documents, or a feed that re-reads everything on every open, can often be fixed with counters, aggregation queries, pagination or caching. Measure which screens cause the reads before you decide. Our guide to controlling cloud costs for a small SaaS covers the same habit on AWS.
Do you have to leave Firebase completely?
Usually not. Firebase is several products, and most of them work fine next to your own back end. A common target looks like this:
- Keep: Authentication, Cloud Messaging for push notifications, Crashlytics and Remote Config.
- Move: the main data to a relational database behind your own API, built with a framework such as Laravel or Node.js; our comparison of Laravel and Node.js back ends helps with that choice.
- Replace as needed: Cloud Functions with jobs on your own server, and Firestore security rules with checks in the API.
There is also a middle path: Firebase offers its own fully managed PostgreSQL database, powered by Cloud SQL and integrated with Firebase Authentication (Firebase SQL documentation). Compare it with running your own before you decide.
How do you move the data?
Firestore's managed export writes your documents to a Cloud Storage bucket, but it needs the Blaze plan, it is not an exact snapshot of one moment (changes made during the export may be included), and the files use the LevelDB format. Exports can be loaded into BigQuery only when you export specific collections (Firestore export and import).
For a live app, a script that reads through the Admin SDK and writes into the new tables is usually easier to control. Plan these points:
- Map documents to tables. Nested maps and subcollections become related tables; keep the original document IDs so references still work.
- Decide how writes are handled during the move. Either write to both stores for a period, or pause writes for one area while it moves.
- Move files too. Images and uploads in Cloud Storage need new paths in the new database.
- Check the counts. Compare record totals and a sample of records in both stores before switching reads.
How do you move user accounts?
If you keep Firebase Authentication, nothing moves: your API verifies the Firebase ID token on each request. If you do move accounts, the Firebase CLI's auth:export command writes users to JSON or CSV. It only exports password hashes made with Firebase's scrypt algorithm; accounts hashed another way export with empty hash fields (Firebase CLI auth commands).
Firebase uses a modified version of scrypt with hash parameters unique to each project, which you find in the Firebase console (Firebase user import guide). Your new sign-in code verifies passwords with those parameters and re-hashes them with your own method at the next sign-in, so nobody has to reset a password. Treat the hash parameters as secrets; the Firebase CLI guide calls them sensitive (Firebase CLI auth commands).
What does a staged move look like?
- Build your own API next to Firebase and put new features on it first.
- Release an app version that reads one area through the API while the rest stays on Firestore.
- Copy that area's data, keep it in sync, compare it, then switch reads and writes for good.
- Repeat area by area, then retire the security rules and functions that are no longer used.
The step teams forget: old app versions keep reading and writing Firestore directly until people update. Keep Firestore in sync for them, or use a minimum version check to move users to a supported version before you switch an area off.
Running your own back end adds servers, backups, monitoring and security updates. Our cloud and DevOps team and Laravel development team plan that work, and its monthly cost, before the first collection moves.
Frequently asked questions
Is Firebase too expensive for a growing app?
Not by default. Many apps run on it cheaply for years. Costs grow when the data model forces many reads per screen, when live listeners watch large result sets, or when reports scan whole collections. Fix those first: often a better structure, counters or caching cuts the bill without moving anywhere.
Can we keep Firebase Authentication and move only the database?
Yes, and it is often the safest first step. The app keeps signing in with Firebase, sends the Firebase ID token with each request, and your own API verifies that token before reading the new database. Users notice nothing, and you can decide about moving accounts later, or never.
Will users have to reset their passwords if we move accounts?
Not if the move is planned well. Firebase can export password hashes made with its modified scrypt algorithm, and your new back end can verify them with the project hash settings, then re-hash each password with your own method at the next sign-in. Social sign-ins are linked again by provider ID.
Which database should we move to?
For most business apps, a relational database such as PostgreSQL or MySQL, because reports, joins and transactions are usually the reason for moving. Choose the database your team can run and back up well. If you want to stay close to Firebase, its own managed PostgreSQL option is worth comparing.
How long does a move off Firebase take?
It depends on the number of collections, how much logic lives in security rules and Cloud Functions, and how many app versions are in use. A staged plan lets you ship value early: new features on the new API first, then one area of data at a time, with the old path kept as a fallback.
Last updated