Firebase Pricing 2026: Plans, Costs and Free Limits
Oct 28, 202614 min read
Firebase is Google's app backend platform for databases, auth, hosting and serverless functions, and teams that wire it into workflow tools such as Activepieces often start by checking what it costs.
It has two plans: Spark, which is free with fixed quotas, and Blaze, which is pay-as-you-go with no flat fee.
Firebase pricing is the usage-based billing model for Google's Firebase services, in which the free Spark plan caps each product at fixed quotas and the Blaze plan charges per unit for metered usage such as database reads, function invocations and network egress.
You pay on Blaze only for usage past each product's free quota, so the bill depends on how many reads, function runs and bytes of egress your app produces.
Firebase pricing plans and free tier limits compared
Spark and Blaze in one table
Spark stops at the limit, while Blaze keeps serving and starts billing.
| Spark | Blaze | |
|---|---|---|
| Monthly price | Free | No fixed fee, billed on usage |
| What is included | Core products inside fixed no-cost quotas | Everything in Spark, plus products that require billing |
| Firestore reads and writes | No-cost quota, then operations are refused | Same no-cost quota, then billed per operation |
| Functions | Not available for new deployments | No-cost invocation quota, then billed per run and compute time |
| Storage | Limited for newer projects | No-cost quota, then billed for storage and egress |
| Hosting | No-cost storage and transfer quota | Same quota, then billed per unit |
| Auth | No-cost quota for most sign-in methods | Same, with some methods billed beyond it |
Because I haven't re-checked the pricing page for this integration, confirm any limit there before you plan around it.
Free quotas per product: Firestore, Storage, Hosting, Auth, Functions
Firestore counts document reads, writes and deletes, Storage counts bytes stored and downloaded, Hosting counts stored files and transfer, Auth counts active users, and Functions counts invocations plus compute time.
On Spark, several things don't run at all, so the upgrade comes early:
- Cloud Functions for new deployments
- Cloud Storage buckets on newer projects
- Firebase Extensions, which install functions behind the scenes
If your prototype uses any of these, assume you're on Blaze from the first deploy.
If you are running this arithmetic for your own team, see what the same workload costs on Activepieces.
Real Firebase bills on Blaze
On Blaze, a hobby app costs about nothing, a 5,000-daily-user app about $9 a month, and a 100,000-user app about $283. The cap you set should be sized to egress as much as to database reads.
Open the Usage tab for Firestore and Functions and note monthly reads, writes, invocations and outbound data. These are the units Google meters.
Enter each count in Google's pricing calculator and pick your region first. Per ReadMeter, reads run $0.03 to $0.06 per 100,000. Writes run $0.09 to $0.18, and deletes $0.01 to $0.02.
The low end is single-region and the high end is multi-region, so choosing multi-region doubles your Firestore read and write costs.
Firebase cost estimates for three example workloads
I assumed 60 reads and 10 writes per user per day, 20 function calls per user per day, and 30 days. I used single-region rates, $0.40 per million invocations after 2 million, and $0.12 per GB after 5 GB.
I ignored the daily free quotas, so each total is slightly high. These are estimates from October 2026, so re-enter them in the calculator before you rely on them.
| App | Reads | Writes | Invocations | Egress GB | Cost per line | Monthly total |
|---|---|---|---|---|---|---|
| Hobby | 1M | 200k | 100k | 2 | $0.30 / $0.18 / $0 / $0 | $0 after free quotas |
| 5,000 daily users | 9M | 1.5M | 3M | 50 | $2.70 / $1.35 / $0.40 / $4.80 | about $9.25 |
| 100,000 users | 180M | 30M | 60M | 1,500 | $54 / $27 / $23.20 / $178.80 | about $283 |
At 5,000 daily users, egress is already the largest line, at about half the bill. At 100,000 users it's about 63%, so shrinking payloads saves more than trimming reads.
At the top end, region matters. Multi-region doubles the read and write lines. That lifts the 100,000-user total from $283 to about $364.
That extra $81 a month buys redundancy you may not need, so confirm the choice before you create the database.
Spot hidden Firebase costs and limits
Unless you add them by hand, your own row will miss five charges. They are Firestore read multiplication, Functions build and egress fees, SMS sign-in, Storage and Hosting bandwidth, and the lack of a hard cap on Blaze.
Read and listener multiplication in Firestore
Firestore meters one read per document returned, not per query. A screen that loads a 50-document list is 50 reads, and a real-time listener bills again for every document that changes afterward.
Paginate with limits, listen only to the documents on screen, and count reads per screen in your estimate.
Functions, build and egress charges
The unit here is the invocation, but two other lines ride along. Each deploy builds a container image through Cloud Build and stores it in Artifact Registry, so frequent deploys leave a growing storage charge.
Data your functions send out of Google's network is billed as egress beyond the free allowance.
Set a cleanup policy on old images and keep large payloads out of function responses.
Phone auth and other per-use fees
Phone sign-in meters one SMS per verification, and the price depends on the destination. OpenAPI Pricing lists $0.01 per SMS for the US, Canada and India, $0.04 for the UK, $0.05 for Brazil, and $0.06 for most other countries.
At the $0.06 rate, 10,000 verifications cost $600, against $100 at the $0.01 rate. Retries and bots add to it.
Restrict SMS to the regions you serve, and offer email link or Google sign-in as the default.
Serve one 5 MB image to 20,000 visitors and about 100 GB moves. Storage and Hosting bill bandwidth the same way, per gigabyte downloaded.
Compress images and set long cache headers.
No hard spending cap on Blaze
Blaze has budget alerts, and they only notify you. They don't stop usage, so a loop or a bot can keep running while the email waits unread.
There is a workaround, which Google documents: a budget notification triggers a function that disables billing on the project. That shuts your app off, and billing data lags, so the cut-off lands after the overspend begins.
Set the alert near your estimate, add the shutdown function for a prototype, and treat both as a limit on the loss, not a ceiling.
Worth checking against a plan that does not meter every step: one credit covers a whole run on Activepieces.
Compare Firebase, Supabase, Amplify and Appwrite
Firebase is usually cheapest when your app does little work per user, because it bills per operation. Supabase, Amplify and Appwrite lean on plan or resource pricing that sets a higher floor but a steadier bill.
Firebase is usually cheapest when your app does little work per user, because it bills per operation.
Free tiers side by side
All four vendors offer a free entry point, but they differ in what happens when you outgrow it. Firebase's Spark plan stops the metered service rather than charging you, so a spike costs you uptime, not money.
The others also restrict or pause free projects, which means a prototype can go quiet without warning.
Two columns decide your bill: what you're metered on, and what happens past the limit. The table compares the four on those.
| Vendor | Billing model | Behaviour past limits |
|---|---|---|
| Firebase | Per operation: reads, writes, function runs, egress | On Blaze, keeps running and bills the overage; no cap unless you build one |
| Supabase | Per resource: a project plan with usage allowances | Paid plan can hold a spend cap; past it, you pay overage or lose headroom, depending on the setting |
| AWS Amplify | Per operation, billed through underlying AWS meters (builds, hosting, requests) | Keeps serving and bills at metered rates |
| Appwrite | Per resource: a plan tier with usage allowances | Free projects are restricted; paid plans bill overage |
When traffic is low, the per-operation vendors reward you, and they punish a runaway query. The per-resource vendors charge a base price even when nothing happens.
Firebase vs Supabase cost at each workload
Firebase wins when the workload is light and spiky: few reads per session, occasional function runs, little egress. You pay only for what happens, and the alert and shutdown function from the previous step bound the downside.
It loses when one unit dominates and repeats. A read-heavy feed or a chatty listener multiplies reads, and a per-resource plan with a fixed allowance then costs less and is easier to forecast.
So price your own three meters first, then pick the model. If your estimate sits well under a plan's base price, Firebase is cheaper. If it sits above, a per-resource plan is.
Set Firebase budget alerts and caps on Monday
Monday's job is a budget with alerts, quotas on the metered services, App Check on your backends, and leaner reads.
- In the Google Cloud console, open Billing > Budgets & alerts > Create budget, and scope it to the project behind your Firebase app. A project-scoped budget means a runaway test project can't hide inside a shared account total.
- Set the amount to your 30-minute estimate. An alert measured against your own forecast tells you when reality has drifted from the plan.
- Under Set alert threshold rules, add 50%, 90% and 100% of the budget. At 50% you learn early that usage is running ahead of forecast. At 90% you still have time to act. At 100% you have already overspent.
- Open IAM & Admin > Quotas & System Limits and lower the limits on the services you metered, such as Cloud Functions invocations. A lowered quota makes a loop or abusive client fail visibly instead of billing quietly.
- In the Firebase console, go to Build > App Check, register each app, and enforce it for Firestore, Cloud Storage and Cloud Functions. Enforcement rejects requests from clients that aren't your app, so scrapers can't run up your reads and egress.
With limits in place, shrink the line most likely to grow.
- In the Firebase console, open Build > Firestore Database > Usage and find which collections generate the most reads. Optimizing the top collection first pays back more than tuning everything evenly.
- Add
limit()and pagination to list queries, so a screen that shows ten items stops fetching hundreds. - Enable offline persistence or cache results on the client, so repeat visits are served locally instead of billed again.
- Replace broad real-time listeners with one-time reads where live updates aren't needed. A listener bills for every change it delivers, and one left open on a busy collection never stops.
It is easy to miss an alert sent to a billing contact's inbox. In the budget's Manage notifications section, add team email addresses, and connect a Pub/Sub topic if you want the alert to reach a chat channel or a workflow tool.
What Activepieces does about this
Activepieces doesn't change Firebase's meters and can't cap Blaze, so the shutdown function and the lowered quotas stay Google's job. What it fixes is the weak point named earlier: a budget alert that nobody reads.
A Pub/Sub push subscription on the budget topic can post to a flow's webhook trigger, and the flow can do the work that an email leaves to a person.
It can pull the project name and spend out of the payload, compare it with the 50%, 90% and 100% thresholds you set, and post to the right Slack channel.
It can also append a row to a Google Sheet, so you have a running record of when each threshold was crossed.
Cost is easy to forecast, which suits an article about forecasting. A run is billed at 1 credit however many steps it has, so a ten-step flow that checks spend, tags the project and pings a channel costs the same as the two-step version.
The free plan gives you 1,000 credits a month and unlimited flows. A budget alert fires a handful of times a month, so even several projects stay far inside that allowance.
If you'd rather not send billing data to a hosted service, the core of Activepieces is MIT-licensed and self-hostable, so the same flow can run on your own infrastructure.
Build the flow on Monday, right after you create the budget, and trigger it once with a test message before you rely on it. An alert that reaches a channel people watch is what turns the 90% threshold into time to act.
Frequently asked questions
The budget alert covers spend you can see coming. These questions cover the cases where the plan itself decides what happens.
Is Firebase really free?
Yes on Spark, within limits. Spark costs nothing, but each product has a quota, and some features sit behind the paid plan entirely, such as deploying Cloud Functions. Blaze keeps free quotas for many products and bills only the usage above them.
After upgrading, a small app can therefore still land on a bill of zero, but you're now exposed to overage if traffic spikes.
Can I downgrade from Blaze back to Spark?
Yes, you can move a project back to Spark by removing its billing account in the console.
Two consequences follow. Anything that needs Blaze stops working, so functions you deployed may go offline. Usage you already accrued is still billed, so downgrading ends future charges and doesn't erase the current invoice. Check which of your features depend on Blaze before you switch.
Does Firebase need a credit card?
Not for Spark, but yes for Blaze. Blaze requires a billing account with a payment method attached, because the plan is billed after the fact.
That's the reason the budget alert from the previous step matters: the card is charged for whatever the meters recorded, with no prepaid balance to run out first.
What happens if I exceed the free quota on Spark?
The affected service stops serving requests until the quota resets, and you're not charged. The reset period depends on the product, and some quotas renew daily while others renew monthly.
For a prototype, that means the cost of a traffic spike is an outage, not a bill. For a launched product, an outage is usually the worse outcome, which is the main reason people move to Blaze.
Is Firebase cheaper than Supabase for a small app?
It depends on which unit your app hits hardest. Firebase's database bills per document read and write, so a chatty screen that refetches often costs more than the same app with fewer, larger queries.
Supabase charges a base fee for the plan with usage included, and bills overage on top. A read-light app with modest traffic often costs less on Firebase's free quota.
A read-heavy app is easier to predict on a flat base fee. Count your reads per user session on both pricing pages before you decide.
Related reading
References
Running the numbers
See what the same workload costs here.
Free forever plan, and every paid plan self-hosts at no extra cost.
See pricing Talk to sales
