How Firebase pricing actually works
The Spark plan is free but capped — when you hit the limit, things stop working. The Blaze plan is pay-as-you-go with the same free quota included every month, and it does not stop. That is exactly why bills surprise people: there is no ceiling by default.
Blaze bills each service separately. Firestore charges per document operation, Storage per gigabyte stored and downloaded, Functions per invocation plus compute time, Hosting per gigabyte transferred. Most apps find that one of these dominates and the rest are noise.
Firestore reads are what get you
Reads cost $0.06 per 100,000, which sounds trivial until you count properly. A dashboard with a real-time listener on a 50-document collection charges 50 reads every time it opens, and again on every change. Ten thousand users opening it five times a day is 75 million reads a month.
The four fixes that usually work, in order of impact:
- Paginate everything. Never fetch a collection without a limit.
- Denormalise for the read path. Store a summary document so a list view is one read, not fifty.
- Cache on the client. Firestore offline persistence serves repeat views from disk for free.
- Use listeners deliberately. A real-time listener on a busy collection is a subscription to a bill.
What the free tier covers
Per month on Blaze, before you pay anything:
- Firestore: 1.5 million reads, 600,000 writes, 1 GiB stored
- Cloud Storage: 5 GB stored, roughly 30 GB downloaded
- Cloud Functions: 2 million invocations, 400,000 GB-seconds of compute
- Hosting: 10 GB of transfer
- Authentication: free for standard providers; phone/SMS is billed separately
A pre-launch app or a small internal tool genuinely runs at zero. The bill appears somewhere between 5,000 and 20,000 active users, depending entirely on how chatty your read path is.
Is Firebase the right choice?
For an MVP, usually yes. You get auth, database, storage, functions, hosting and analytics without hiring anyone to run infrastructure — which is worth more than the bill for the first year of most products.
It gets expensive when your access patterns are read-heavy and relational, or when you need complex queries and aggregations that Firestore does not do natively. At that point a managed Postgres on AWS is often cheaper and more predictable — but it needs someone to look after it. If you are weighing the two, our backend development team does this assessment regularly.