Firebase pricing comes down to two plans: Spark, which is free within fixed usage limits and needs no billing account, and Blaze, which is pay as you go and still gives you the free quotas before it charges. For most startup apps, the bill is driven by Firestore reads, Cloud Functions, file downloads and SMS sign-ins, not by user count alone.
| Item | Spark (no cost) | Blaze (pay as you go) |
|---|---|---|
| Billing account | Not required | Required |
| When you pass a free quota | That product stops until the quota resets | The app keeps running and the overage is billed |
| Firestore free quota | 50,000 reads and 20,000 writes per day | Same free quota, then billed per operation |
| Cloud Functions | Not available | Available, billed on usage |
| Cloud Storage | Free allowance, then blocked | Free allowance, then billed for storage and downloads |
| Authentication | Email and social sign-in rarely a cost issue | SMS and phone verification billed per use |
| Spending cap | Built in, because nothing is billed | None built in; budget alerts only |
Firebase pricing is built on two plans. Spark is the no-cost plan with fixed usage limits for each product. Blaze is pay as you go: you attach a billing account, you still get the free quota for each product, and you pay only for usage above it. Costs then follow how much your app reads, stores and runs.
Firebase is a bundle of separate products: Firestore, Cloud Storage, Hosting, Authentication, Cloud Functions and more. Each has its own free allowance and its own meter. That is why two apps with the same number of users can have very different bills.
The prices themselves change, and they are published in US dollars with different rates by region. Before you budget, open the current Firebase pricing page and the Firestore pricing table for the region you will use. We quote rates below only where we are confident of them, and we tell you where to check the rest. Also confirm how your invoice is converted to pounds or euros, and how VAT applies to your company.
At Axire Infotech we build MVPs on both Firebase and Supabase, using React, Next.js, Node.js and React Native. The patterns below are the ones that matter when you are sizing a first release. For the other side of the coin, our Supabase pricing breakdown covers a flat-fee-plus-usage model.
The difference is what happens at the limit. On Spark, going over a product's free quota stops that product until the quota resets, and you are never billed. On Blaze, the app keeps running and you are charged for the overage. Blaze also unlocks products such as Cloud Functions that Spark does not offer.
That makes Spark safe but fragile. A launch-day spike can switch off your database reads for the rest of the day. Blaze removes that risk and replaces it with a different one: the app stays up, and the cost is open-ended.
| Question | Spark | Blaze |
|---|---|---|
| Can I get billed by accident? | No | Yes, if usage passes the free quotas |
| Can a spike take the app down? | Yes, when a quota runs out | Not for quota reasons |
| Can I run server code in Cloud Functions? | No | Yes |
| Is it suitable for production? | Only for very small or internal apps | Yes |
| Do I still get free allowances? | Yes | Yes, per product |
Stay on Spark while you are prototyping, testing with a handful of users or running an internal demo. Move to Blaze the day real customers depend on the app, or the day you need Cloud Functions for payments, emails or webhooks. We would not run a paid product on Spark, because a quota stop looks like an outage to your customers.
The move to Blaze is not a leap into big bills. For a small app, usage often stays inside the free quotas for months. What changes is that you now need a budget alert and someone who reads it.
Four areas drive most startup bills: Firestore (document reads, writes, deletes, index entries and stored data), Cloud Storage (stored files and downloads), Cloud Functions (invocations, compute time and networking) and Authentication when you use SMS sign-in. Email and social sign-in is rarely the problem.
Firestore charges for the number of documents you read, write and delete, the index entries read to answer a query, and the data you store, including index overhead. The free quota is 50,000 reads and 20,000 writes per day, and it refreshes at midnight.
The detail that surprises founders is that a read is per document, not per request. A query that returns 40 documents is 40 reads. A screen that loads a list of 40 items and re-runs on every visit adds up fast.
For US regions, the published rate for document reads has been around $0.03 per 100,000, but rates differ by region and change over time, so check the current table for your region, for example a European one.
Stored files have a monthly allowance, and beyond it you pay for storage and for data downloaded. Downloads are the part that creeps. A product image served from a public bucket on every page view is billed each time, so large uncompressed images cost more than you expect.
Functions are billed on how often they run, how long they run and how much memory they use, plus outbound network traffic. A well-written function that runs a few thousand times a month is cheap. A function that triggers itself is not, and we cover that below.
Standard sign-in with email and social providers is not where startups see charges. Phone sign-in is different, because each text message has a real cost to deliver, and the rate depends on the destination country.
Firebase has also recently added Phone Number Verification, which sends no text message and has been adding carrier networks, including Vodafone in Germany and Ireland. If you can, ask users for email or social sign-in first and offer phone verification only where it earns its cost. Check the Authentication pricing section for current phone rates.
Hosting has its own storage and transfer allowances, and the other products each carry their own meters. For a typical MVP they are minor next to Firestore and Functions. Look at them once at launch, then spend your attention on the big four.
A small startup app often costs little to nothing at first, because Firestore's free quota covers 50,000 reads and 20,000 writes per day. Costs start when reads per user climb. In an illustrative case, 5,000 daily users making 100 reads each cost about four US dollars a month in reads, at a US-region rate.
The three examples below are hypothetical, built to show the method. They use a rate of $0.03 per 100,000 reads, treat the daily free quota as a monthly average over 30 days, and ignore writes, storage and functions. Your real bill will differ, so redo the sums with the current rate for your region.
Suppose 300 people use the app each day and each makes 60 reads. That is 18,000 reads a day, well inside the 50,000 free reads. The Firestore read cost is zero. On Spark this app would run happily; on Blaze it would also cost nothing for reads.
Now 5,000 people use the app daily and each makes 100 reads. That is 500,000 reads a day. Subtract the 50,000 free reads and 450,000 are billable. Over 30 days that is 13.5 million reads, or 135 blocks of 100,000. At $0.03 each, the read cost is about $4.05 a month.
That is a small number for an app of that size. It shows why Firebase suits early products. Writes, storage, function runs and any SMS sign-ins would be extra, but a founder planning a seed-stage budget can treat this as the right order of magnitude, not a scary one.
Say a home screen listens to an entire collection, and every change pushes the full list to every open session. Each user now generates 2,000 reads a day instead of 100. For 5,000 daily users that is 10 million reads a day. After the free 50,000, about 9.95 million are billable, or roughly 298.5 million over 30 days. That is 2,985 blocks of 100,000 reads, about $89.55 a month.
The user count did not change. The query did. Reads rose twentyfold and so did the bill. This is the pattern we see most in Firebase projects, and it is why we review data access before launch and not after the first invoice. For a wider view of what an MVP costs beyond hosting, see our guide to MVP development cost in 2026.
Surprise bills come from usage that grows faster than users do. The usual causes are real-time listeners that re-read whole collections, queries without limits, Cloud Functions that trigger themselves in a loop, public files downloaded repeatedly, and SMS sign-in abused by bots. A missing budget alert means nobody notices until the invoice arrives.
A real-time listener on a whole collection re-reads documents whenever the data changes. If the collection holds 2,000 documents and 50 of them change during a session, the cost depends on how the listener is written. Add a limit, paginate, and listen to a single document or a filtered query where you can.
A function that fires when a document changes, and then writes to the same document, will run again and again. Each run costs compute time, and each write costs a Firestore write. Guard these functions with a check that stops the loop, and test them on a small dataset first.
If a file in Cloud Storage is public, anyone can download it as often as they like, including other websites that link to it. Resize images before upload, serve thumbnails for lists, and put a CDN or caching headers in front of heavy assets.
Phone sign-in invites automated abuse, where bots request verification codes in bulk and you pay for each message. App Check helps because it checks that requests come from your genuine app. Limiting the countries you send to is also sensible, as is choosing email or social sign-in as the default.
The most common cause is organisational. Nobody set a budget alert, and nobody was responsible for opening the usage dashboard. The technical bug is then found a month late.
Set a budget alert before launch, then reduce reads at the source: paginate lists, cache results, listen to single documents instead of collections, and lock down security rules. Add App Check to block traffic from outside your real app, and review the usage dashboard weekly during the first month after launch.
Be clear on one point: a Google Cloud budget alert tells you spending is rising, but it does not stop it. If you want a hard stop, you have to build automation that reacts to the alert, and test it, because cutting billing takes the app offline.
If a check fails, fix it before launch. A listener you cannot justify, or a function you cannot explain, is the one that will appear on the invoice.
Reconsider Firebase when your bill grows mainly from read-heavy, relational data, or when you need predictable monthly pricing and SQL. If reads dominate and your data is joined across collections, a Postgres backend can be easier to forecast. If your app is mobile-first with real-time sync and modest traffic, Firebase usually stays the cheaper, faster choice.
Firestore is a document database, so reports, joins and filters across many fields can mean many reads or extra indexes. Founders who expect heavy reporting, or who want a flat plan fee, often find a Postgres-based backend easier to budget. Our Firebase vs Supabase for MVP development article weighs that decision in full, so we will not repeat it here.
Be honest about what is unsettled. Firebase's product lineup and rates keep changing, and we cannot tell you what your bill will be in 18 months. What you can do is measure reads per active user in the first month and project forward from that number.
Firebase is free on the Spark plan within fixed limits, and Blaze also includes free quotas before it bills. So a small app can run at no cost on either plan. You only pay once usage passes a product's free allowance, which is why monitoring matters more than the plan name.
No, Blaze has no built-in hard cap. Budget alerts in Google Cloud notify you at thresholds you choose, but they do not stop spending by themselves. To enforce a cap, you need to build automation that disables billing or services when an alert fires, and you should test it, because disabling billing takes your app offline.
Firestore's free quota is daily: 50,000 reads and 20,000 writes per day, refreshed at midnight. Other products use monthly allowances. That matters because a single traffic spike can use up a day's free reads, and on Blaze the extra reads are billed rather than blocked.
A Firebase estimate is only useful if it starts from your actual screens, queries and sign-in methods. We are a lean studio based in India that works remotely with startups and businesses across Europe, with overlap with CET afternoons, and we reply to inquiries within 2 hours during business hours.
If you want help sizing the backend for an MVP, our team can map your reads, functions and auth costs before you commit. Explore our React Native app development and UI/UX design services, see our projects, or browse all services. For related reading on build costs, try our guide to what drives startup web app development cost or more articles on the blog.
Ready to put numbers on your own app? Contact Axire Infotech with your feature list and expected users, and we will help you choose between Spark, Blaze or another backend before you write a line of production code.
Let's discuss your project and create something amazing together.
