Firebase Pricing in 2026: What You Actually Pay

Firebase pricing starts at zero and stays there for a lot of apps. The free Spark plan is genuinely generous, and Google hands you a $300 credit the day you upgrade. The trouble starts later, when a real app crosses the free quota, discovers that Firestore charges per read, and learns that Firebase has no hard spending cap. This teardown walks the 2026 rate card, then builds three real 30-day bills, including the runaway one that shows up in every horror-story thread.

What does Firebase cost in 2026?

Firebase has two plans. Spark is free and stays free within daily quotas. Blaze is pay-as-you-go: you keep the same free allowances, then pay per unit above them. Here is what the free tier covers in 2026, pulled from Firebase's 2026 pricing page.

Two products dominate almost every Firebase bill: Cloud Firestore and Cloud Functions. The rest are usually rounding error until you serve large files or heavy traffic. So the number that matters is the Firestore rate card.

The Firestore rate card that actually drives your bill

Firestore does not charge for storage the way most databases do. It charges for operations: every document your app reads, writes, or deletes is metered. Here are the 2026 Blaze rates from Google's own worked billing example, for the United States multi-region.

Reads are the cheapest per unit and the most dangerous, because a real app does far more reads than writes, and it is trivially easy to read thousands of documents by accident. Hold that thought.

Three real 30-day Firebase bills

Sticker rates mean nothing without usage. Here are three cohorts, built on the same per-user intensity Google uses in its official example: about 80 reads and 20 writes per daily active user per day.

Cohort 1: a hobby app, 5,000 DAU, about $12/month

This is Google's own published example, so the arithmetic is theirs, not mine.

• Reads: 400,000/day, minus 50K free, = 3.5 units at $0.06 = $0.21/day, so $6.30/month
• Writes: 100,000/day, minus 20K free, = 0.8 units at $0.18 = $0.14/day, so $4.20/month
• Deletes and storage: about $1.64/month
• Total: about $12.14/month

At this scale the free daily quota absorbs a big slice of usage, so the effective rate is roughly $2.43 per 1,000 DAU per month.

Cohort 2: a growing app, 50,000 DAU, about $134/month

Same per-user intensity, ten times the users. Now the free quota is a rounding error.

• Reads: 4,000,000/day, minus 50K free, = 39.5 units at $0.06 = $2.37/day, so $71.10/month
• Writes: 1,000,000/day, minus 20K free, = 9.8 units at $0.18 = $1.76/day, so $52.92/month
• Deletes: about $1.08/month
• Storage (40 GiB) plus egress (25 GB): about $8.82/month
• Total: about $134/month

Effective rate: about $2.68 per 1,000 DAU per month. Notice reads alone are $71 of the $134, which is 53% of the bill. On a healthy Firestore app, reads are the line item to watch.

Cohort 3: the runaway, 50,000 DAU, about $5,540/month

Same app. One difference: the home screen calls getDocs() on a 2,000-document collection with no limit(), and it runs every time the app opens, about three times per user per day.

• Extra reads: 50,000 times 3 times 2,000 = 300,000,000 reads/day
• Billable: 3,000 units at $0.06 = $180/day, so $5,400/month, from one screen
• Plus the $134 baseline, about $5,540/month

That is a 40x jump from a single missing .limit(). Reads do not show up in code review the way a slow query does, so this pattern ships to production constantly.

Why Firebase has no hard spending cap

Cohort 3 is the tame version. The threads are worse. One developer posted a $121,000 bill in two days after a Cloud Function using the Translate API looped on itself. Others have woken up to five-figure bills after a denial-of-service attack hammered an unprotected endpoint. There is a long-running community petition asking Google for a hard billing limit, and the answer is still no.

Here is the mechanic every new Firebase developer eventually learns: a budget alert is not a spending cap. It emails you after money is spent, often hours late. The only real hard cap is a workaround you build yourself: a Cloud Function subscribed to a budget Pub/Sub alert that calls the Cloud Billing API and disables billing when spend crosses a line. It is a documented pattern, and it should be the first thing you deploy on any Blaze project.

Firebase vs the flat-fee alternatives

Usage-based pricing is a feature when traffic is small and a liability when it spikes. If predictability matters more than scale-to-zero, flat-fee backends change the risk shape.

Supabase runs on Postgres and prices its flat Pro tier at $25/month with defined usage allowances, so your worst case is bounded by the plan, not by an unbounded read loop. AWS Amplify with DynamoDB is also usage-based and carries the same variance risk as Firestore. Appwrite, self-hosted, is a fixed server cost with no per-read meter at all, at the price of running your own infrastructure.

None of these is strictly cheaper. Firebase's free tier and scale-to-zero are genuinely hard to beat for early apps. The real question is whether you would rather pay a known monthly number or a metered one that can spike while you sleep.

How to actually keep the Firebase bill down

The bill is reads, so the fixes are about reads.

1. Put a .limit() on every query. An unbounded getDocs() on a growing collection is the single most common runaway.
2. Cache reads on the client and paginate. Do not re-read a whole collection on every screen mount.
3. Denormalize counters. Store a count field and increment it; do not read 10,000 documents to show a total.
4. Watch Cloud Functions for loops. A function that writes to a collection it also listens to is an infinite bill.
5. Deploy the billing kill-switch function on day one. It is the only real hard cap Firebase has.

Do those five things and a 50,000-DAU app stays near the $134 line instead of the $5,540 one.