I would be wary of a project proposal that settles on Firebase before anyone has looked at the reports the business needs. It puts a long-term decision in the hands of whichever tool makes the first few screens easiest to build.
There are good reasons to use Firebase. Google provides services for storing data, signing people in and keeping screens updated, which can save a small team considerable setup work. The trouble starts when that convenience becomes the whole reason for choosing it.
For a business app, I’d want the team to explain how the choice will hold up when staff correct an old invoice, the owner asks for a different report, or the company wants another hosting provider. Those are ordinary requests. They belong in the original decision.
Take a hypothetical catering business building a booking app. We can follow that one example far enough to see where Firebase needs a closer look.
Try the report before approving the database
The first booking screen needs a customer, an event date and a menu. Later, the owner wants to know which events actually made money. Now the answer involves ingredient purchases, staff time, deposits, refunds and an invoice that was corrected after the event.
That changes the discussion. The important question is how those records relate to each other and stay correct when something changes.
Cloud Firestore stores documents in collections. A developer might keep a copy of the customer’s details with each booking, or maintain a separate summary for a report. Both can be sensible choices. But if a supplier cost is corrected, someone has to decide which summaries need recalculating and how to recover if an update fails.
A relational database, such as PostgreSQL, is worth comparing here because the business already depends on connections between records. It still needs careful design. I’d ask both proposed designs to produce the same profit report, then correct a payment and run it again. Watching that happen tells an owner more than being told the platform will scale.
Be specific about the Firebase product being proposed. Firebase SQL Connect uses PostgreSQL, so “Firebase cannot handle relational data” would be an inaccurate criticism. It is a different choice from Firestore, with its own costs and integration work. The brand name alone does not tell you which design you are buying.
Price the screen your users keep opening
In the booking app, staff may return to the order list throughout the day. With Firestore, the number of people using that screen is only the beginning of a cost estimate.
Here is a deliberately simplified calculation. Suppose an app has 1,000 daily users, each opening a list five times. If every opening fetches 60 documents from the server, that is 300,000 document reads a day. This is an assumed workload, not a customer result or a claim about what every app will cost.
Firestore’s billing rules also account for live changes and, under certain conditions, reads when a disconnected listener reconnects. The client’s offline settings matter. Storage and data transfer add other costs. A shorter query or effective caching can reduce the work substantially; “1,000 users” on its own cannot give you a useful price.
This is where I’d ask a developer to show the requests made by that busy screen and explain which ones are necessary. If it keeps fetching records nobody is looking at, fix that before discussing a larger budget.
Spending controls need the same attention. On the usage-based Blaze plan, an ordinary budget alert sends a warning rather than stopping the bill. Google does now offer spend caps in preview for selected services, including AI Logic, App Hosting, Cloud Functions for Firebase and Extensions. They do not cover every Firebase service, and reporting delays can allow billed overages. Reaching the cap also pauses the affected service.
For the catering business, that means a spending limit needs an operational answer: what happens to bookings if a service stops? Someone must own that decision and the response to an alert. A budget email sitting unread over a weekend offers very little protection.
A successful login proves very little about access
A customer should see their own booking. A member of the kitchen team may need the menu and headcount without needing every payment detail. The person running the business needs a different view again.
Those distinctions have to hold when someone requests a record directly. Hiding a button is not enough. A useful test tries to open another customer’s booking and checks that the request is refused, even though the person is signed in.
Firestore has Security Rules for client access, while its server client libraries use Google Cloud credentials and bypass those rules. The developer must secure both routes. Managed hosting does not decide which employee should be able to refund a booking.
Login also needs a recovery path. If the app uses SMS codes, account for failed delivery and unwanted automated requests. Google’s Authentication guidance covers billing requirements and SMS abuse. A customer who cannot receive a code still needs help, and switching off protection to make login easier is a poor answer.
Try leaving with one booking
Suppose the business later wants to move the app. “You can export your data” sounds reassuring until the replacement has to do something with it.
Google provides managed Firestore exports. They require billing, and the operation and storage have costs. An ordinary export can include writes made while it runs, so a move also needs a plan for bookings that change during the transfer. Downloading records does not settle that problem.
The app may also rely on Firebase to recognise a signed-in customer, deliver a live update and run an action after a payment. Those behaviours need counterparts in the replacement. Exporting user accounts helps with one part, but password handling must be compatible with the destination; it does not prove everyone will sign in without disruption.
Before committing, I’d ask for a small exit exercise: move a sample customer and booking to a separate test environment. Sign in, change the booking, check who can see it and confirm that the payment record still makes sense. Keep a note of the code that had to change. That gives the owner a realistic basis for discussing future migration costs.
This matters most when the business expects to change providers or needs control over where particular services run. Firebase has location choices that vary by product and resource, rather than one setting covering the whole project. A database region cannot answer for every service used by the app.
What I’d approve for this kind of app
For the catering example, I’d start by comparing a PostgreSQL-backed application with the proposed Firebase design. The reports and financial corrections are central to the product, so I would want those demonstrated early. The team should be able to explain where the business rules live and what happens when an update is interrupted.
That need not mean running everything on your own servers. Supabase offers PostgreSQL as part of its platform, and Appwrite has a self-hosted option. Neither name guarantees a smaller bill or an easy move. Compare the same work, including the people who will maintain it. Paying a developer to manage backups and upgrades is still a cost.
A different app could reasonably end up with Firebase. A small team testing whether people want a live collaboration tool may value the quick setup more than a straightforward future migration. That is a defensible trade when it is deliberate and the usage has been measured.
If your app already uses Firebase and runs well, this is not a reason to start again. Find the actual difficulty first. A wasteful query may need a better query. A reporting problem might justify a separate reporting service. Replacing the entire backend introduces its own cost and disruption.
The proposal I’d approve would show a working report, a busy-day usage estimate, an access test and the results of that small migration exercise. Then there is something concrete to judge. “It was the quickest way to get the app running” would not be enough on its own.
If you are commissioning an app, bring us the booking, order or customer task you need to improve. That is also where we begin with AI development. A working first version should help you make an informed platform choice before the rest of the business depends on it.
