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. It also covers the four things that changed in 2026 that most pricing roundups still miss.

Updated August 24, 2026. Every Spark quota and Blaze rate below was re-verified against Firebase's official 2026 pricing page and Google's Firestore billing example on this date, and all four Standard rates are unchanged: $0.06 per 100,000 reads, $0.18 per 100,000 writes, $0.02 per 100,000 deletes, $0.18 per GiB stored. New this pass: a full Standard-versus-Enterprise rate comparison including the index-write, delete and per-GiB-hour storage lines that most roundups omit, a complete SQL Connect rate card with its two very different free-trial regimes, and a worked cost reckoner from 10 million to 5 billion monthly reads. Firestore Enterprise and SQL Connect figures were read from Google's own docs on August 24, 2026.

Quick answer: Firebase pricing in 2026

Firebase's Spark plan is free and stays free within daily quotas. As of 2026, Cloud Firestore on Spark gives you 50,000 document reads, 20,000 writes, and 20,000 deletes per day, plus 1 GiB stored and 10 GiB/month network egress. Cloud Functions adds 2 million invocations per month, Cloud Storage 5 GB, and Hosting 10 GB. Cross those quotas and you move to the pay-as-you-go Blaze plan, which keeps the same free allowances then charges per unit: $0.06 per 100,000 Firestore reads, $0.18 per 100,000 writes, $0.02 per 100,000 deletes, and $0.18 per GiB stored per month. A typical 5,000 daily-active-user app runs about $12/month. The catch: Firebase has no hard spending cap, so one unbounded query can turn that $12 into thousands overnight. New in 2026, Firebase also has a fixed-floor option, SQL Connect, from about $9.37/month, and a second Firestore edition (Enterprise) priced in size-based units rather than per document.

Firebase Spark (free) tier limits, 2026

Firestore Blaze rates above the free quota, 2026

What changed in Firebase pricing for 2026

Most pages ranking for "firebase pricing" still describe the Firebase of 2023: one Firestore rate card, the retired Flame plan, and the old "no fixed price, no hard cap" summary. Four things changed by 2026, and each one moves real money.

Firestore now ships in two editions. The classic per-document meter is now called Firestore Standard edition. Google added an Enterprise edition (MongoDB-compatible) that prices in size-based units, not documents. Google's Firestore Enterprise pricing charges reads in 4 KiB read units at $0.05 per million read units and writes in 1 KiB write units at $0.26 per million, and it adds an index-write charge per indexed field that Standard includes for free. An 8 KiB document costs 2 read units on Enterprise versus 1 read on Standard. Enterprise wins for tiny 1 to 2 KiB documents and loses for large, heavily indexed ones. A teardown that only quotes "$0.06 per 100,000 reads" now describes just one of the two editions.

Firebase added a fixed-minimum backend: SQL Connect. For years the knock on Firebase was that everything was metered and nothing was predictable. Firebase SQL Connect, managed Cloud SQL for PostgreSQL, breaks that. The smallest instance, a db-f1-micro with 1 vCPU, 10 GB storage, and about 628 MB of memory, runs about $9.37/month whether or not anyone uses it, plus $0.90 per million operations above a free 250,000 per month. Blaze accounts get a 3-month trial (five per billing account). That flips the risk shape: you trade Firestore's runaway-read tail for a base you pay even at zero traffic.

Firebase App Hosting has its own bandwidth meter. App Hosting, the managed full-stack option built on Cloud Run, bills compute plus bandwidth, with the first 10 GiB per month of bandwidth free as of August 1, 2025, per the 2026 pricing page. It is a separate line from Hosting's older 10 GB storage and 360 MB/day transfer allowances, and the two are easy to conflate on a bill.

Firebase Studio is scheduled to shut down on March 22, 2027. The AI app-building workspace launched in April 2025 and is being retired. It does not change the rate card, but it is the Firebase pricing question people keep asking in 2026, so to be clear: Studio going away does not touch your Firestore, Functions, or Hosting bill.

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 on Standard edition.

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.

Firestore Standard vs Enterprise: the full 2026 rate comparison

The two editions are not two price points on one meter. They meter different things, and swapping edition can move a bill in either direction by an order of magnitude. Every Enterprise figure below is from Google's Firestore Enterprise pricing page, read August 24, 2026.

Four things in that table are missed by essentially every Firebase pricing roundup, and three of them are not in Google's own summary either.

Enterprise reads are up to 12 times cheaper, not more expensive. The usual framing is that an 8 KiB document costs 2 read units on Enterprise versus 1 read on Standard, which sounds like a penalty. It is not, because the unit prices differ. One million reads of a document under 4 KiB costs $0.05 on Enterprise and $0.60 on Standard. Firestore's maximum document size is 1 MiB, but the crossover sits at about 44 to 48 KiB of document, far above what almost anyone stores. On reads, Enterprise wins nearly always.

Writes flip the other way at about 7 KiB. Enterprise charges $0.26 per million 1 KiB write units, so a 1 KiB document costs $0.26 per million writes against Standard's $1.80. Enterprise stays cheaper until the document crosses roughly 6.9 KiB, where ceiling-rounded write units overtake the flat Standard rate.

Indexes are what actually move the crossover, and they move it a long way. On Enterprise, indexing a field consumes its own write units: indexing a 2 KiB string field costs 2 write units on every write. Take a 2 KiB document. Bare, it is 2 write units, $0.52 per million. Add one indexed 2 KiB field and it is $1.04. Add a second and it is $1.56. Add a third and it is $2.08 per million, now above Standard's $1.80. A heavily indexed collection can cross over at a document size where the raw write cost looked like a bargain.

Deletes get worse, and nobody budgets for it. Standard deletes are the cheapest meter on the platform at $0.20 per million. Enterprise has no delete rate at all: a delete costs write units. A 1 KiB document delete is $0.26 per million, a 30% premium. A 5 KiB document delete is 5 write units, $1.30 per million, six and a half times Standard. If your workload has a TTL sweep or a nightly purge, price it before you migrate.

Storage is the quiet one. Enterprise publishes storage per GiB-hour rather than per GiB-month, which makes it look cheaper than it is. At 730 hours in an average month, $0.00032 per GiB-hour is $0.234 per GiB per month against Standard's $0.18, about 30% more for the same bytes.

Real-time updates deserve a caveat in both directions. On Enterprise they are a separate line at $0.30 per million read units, six times Enterprise's own regular read rate, which reads badly. But on Standard a listener snapshot is billed as a full document read at $0.60 per million, so Enterprise real-time is still half the price. The reason to care is variance, not level: on Enterprise a chatty listener shows up on its own meter, where on Standard it is buried inside the read line that already drives the bill.

Math check: Enterprise is the cheaper edition for small documents, light indexing, and read-heavy traffic, and it is the more expensive one for large documents, wide indexes, heavy deletes, and large stored volumes. There is no general answer. Multiply your own median document size by your own index count before assuming either direction.

Firebase SQL Connect pricing in 2026

SQL Connect is managed Cloud SQL for PostgreSQL wired into the Firebase SDKs, and it is the only part of Firebase with a floor you pay at zero traffic. Figures below are from Firebase's SQL Connect pricing docs, read August 24, 2026.

Two of those lines matter more than the headline price.

The Spark trial is once per project, forever. Not once per year and not once per billing account: one trial instance per project lifetime, 90 days, with roughly 8,000 operations a day and 330 MiB of egress. Burn it on a throwaway prototype and that project never gets another. On Blaze you get five trials per billing account, which is the number to plan around if you are spinning up several environments.

An operation is a query, not a row. This is the whole economic argument for SQL Connect and it is almost always stated wrong. A screen that pulls 200 documents costs 200 document reads on Firestore, about $0.00012 at the Standard rate. The same screen against SQL Connect is one operation, and the first 250,000 operations a month are free. Above the free tier, SQL Connect operations are $0.90 per million against Firestore reads at $0.60 per million, so SQL Connect is 50% more expensive per unit. It wins anyway, because a relational query collapses a fan-out read into a single billable event. The runaway getDocs() failure mode that produces the $5,540 bill later in this teardown does not have an equivalent here.

Where is the break-even? The $9.37 monthly floor buys you about 15.6 million Firestore document reads at $0.60 per million, or roughly 520,000 reads a day. Below that, Firestore is cheaper and often free. Above it, you are paying SQL Connect's floor for a bill that cannot spike from a missing .limit().

Math check: SQL Connect does not make Firebase cheaper. It makes Firebase predictable, by moving you from an unbounded per-document meter onto a $9.37 floor plus a per-query meter that a bad query cannot multiply. That is a variance trade, and it is worth paying for at any scale where an outage-grade bill would hurt more than $9.37 a month.

A Firestore cost reckoner for 2026

Most people searching for a Firestore pricing calculator want one number: what does this much traffic cost. Below is that table, worked from the verified Standard rates for the US multi-region, with the free tier already subtracted (1.5 million reads, 600,000 writes and 600,000 deletes a month, plus 1 GiB stored).

Read the ratios rather than the totals. Across every row, reads are 69% to 78% of the bill and deletes never clear 1%. Storage only becomes visible past about 100 GiB, and even at 2 TiB it is under 9% of the total. If you are trying to cut a Firestore bill, there is exactly one lever that matters at any scale, and it is the number of documents you read.

One structural discount before you tune anything: those figures are US multi-region. A single-region location such as us-central1 runs roughly half, and choosing it costs nothing at setup.

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.

The newer wrinkle: Firebase itself now has a fixed-floor option in SQL Connect, about $9.37/month base, so the flat-versus-metered choice no longer requires leaving Google's stack. 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.
6. Pick a single region if you do not need multi-region durability. Firestore's rate card is region-scoped: the $0.06 per 100,000 reads above is the US multi-region (nam5) rate, and a single-region location such as us-central1 runs about half that, roughly $0.03 per 100,000 reads, per Google Cloud's Firestore pricing. It costs nothing to choose at setup and is the cheapest structural lever on the bill.

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