Firestore cost calculator
Enter your daily reads, writes, deletes and stored data. Get a monthly estimate with the free-tier allowance subtracted and every step of the arithmetic shown.
Your usage
Enter daily operation counts. The estimate updates as you type.
One read per document returned — a 20-doc query is 20 reads. First 50,000/day are free.
Includes writes made by Cloud Functions and denormalization sync. First 20,000/day are free.
Cascading deletes count one per document removed. First 20,000/day are free.
Total document and index data. First 1 GB is free.
Estimated monthly cost
| Line item | Billable / month | Rate | Cost |
|---|---|---|---|
reads 100,000 − 50,000 free = 50,000/day | 1,500,000 | $0.06/100K | $0.90 |
writes 25,000 − 20,000 free = 5,000/day | 150,000 | $0.18/100K | $0.27 |
deletes 2,000 − 20,000 free = 0/dayfree tier | 0 | $0.02/100K | $0.00 |
Storage 5 GB − 1 GB free = 4 GB | 4 GB | $0.18/GB | $0.72 |
| Estimated total per month | $1.89 | ||
The arithmetic
(daily ops − daily free tier) × 30 days ÷ 100,000 × rate
+ (stored GB − 1 GB) × $0.18
Free operation quotas are granted per day and reset daily, so they are subtracted before multiplying by 30 days — not once per month. Storage is a standing 1 GB allowance.
Estimate only — not a quote. Rates reflect Blaze-plan Cloud Firestore in a US multi-region and change over time. Network egress, Cloud Functions, and other Firebase services are not included. Check Google's official pricing page for the authoritative rates in your region.
How Firestore billing actually works
Firestore bills three things: document operations, stored data, and network egress. Operations are the part that surprises people, because the meter counts documents, not requests. A single query that returns five hundred documents is five hundred reads. A query that matches nothing still costs one read, because Firestore charges a minimum of one for the lookup. Nothing about the shape of your code makes this visible — the same two lines cost a fraction of a cent or several dollars depending entirely on how many documents come back.
The free tier is where most estimates go wrong. It is a daily allowance — 50,000 reads, 20,000 writes and 20,000 deletes, reset every day — plus a standing 1 GB of storage. That distinction matters more than it sounds. If you subtract the allowance once from a monthly total, an app doing 60,000 reads a day looks like it owes for 1.75 million reads. Model it correctly, per day, and it owes for 300,000: ten thousand chargeable reads a day across thirty days. The calculator above does the daily subtraction first, then multiplies, which is why its numbers are usually lower than a back-of-envelope guess.
Storage behaves differently again. It is a standing balance rather than a daily reset, billed per GB per month, and it includes index entries — not just document bodies. Composite indexes on large collections can account for a meaningful share of stored bytes, which is worth remembering before you add an index to every field "just in case."
Where Firestore costs surprise teams
The rates are low enough that nobody budgets for them, so bills grow by pattern rather than by scale. Four patterns account for most of it.
The N+1 read
You load 20 posts, then loop over them to fetch each author document. That is 20 reads plus 20 more — the list doubled in price and nothing on screen changed. N+1 is the single most common reason a Firestore bill outruns the team's mental model, because the second query is usually hidden inside a component rather than sitting next to the first.
Fan-out writes
A user renames themselves and a Cloud Function copies that name onto 500 post documents. That is 501 writes from one tap. Fan-out is often the right design, but it moves cost from the read column to the write column, and writes are billed at three times the read rate.
Listeners that re-read
onSnapshot charges one read per document in the initial snapshot, every time the listener attaches. A screen that mounts a 50-document listener costs 50 reads on each visit, and a component remounting on every navigation quietly multiplies that across a session.
Rules that read
Every exists() or get() inside a security rule is a billed read on top of the operation it guards. Three ownership checks on a document read means four reads. Restructuring rules to test fields already on the document removes the charge entirely.
Denormalization trades storage and writes for reads
Because a write costs three times a read and storage is cheap per GB, the arithmetic of a schema decision is usually decided by how lopsided your read-to-write ratio is. Copying an author's name and avatar into every post document makes the posts slightly larger and adds a sync write whenever that author changes their profile — but it removes a second read from every render of every post, forever. For a feed screen read thousands of times and written once, that trade is not close.
Run it through the calculator with your own numbers. Model the normalized version by doubling your daily reads, then model the denormalized version with the original read count and a few thousand extra writes. The gap you see at today's traffic is the gap that scales linearly with your user count. The inverse also holds: if a field changes constantly and is read rarely, denormalizing it is how you turn a cheap read into an expensive stream of fan-out writes.
For the full treatment of both sides, read the Firestore pricing guide, the data modeling guide, and our denormalization docs, which cover generating the sync functions that keep copied fields correct.
Rates used in this calculator
| Resource | Blaze rate | Free allowance |
|---|---|---|
| Document reads | $0.06 / 100K | 50,000 per day |
| Document writes | $0.18 / 100K | 20,000 per day |
| Document deletes | $0.02 / 100K | 20,000 per day |
| Stored data | $0.18 / GB / month | 1 GB total |
These rates reflect the Blaze plan for Cloud Firestore in a US multi-region. Firestore pricing varies by region and changes over time, so figures here may drift. Network egress is deliberately excluded: it is free within a region and otherwise depends on the destination, so any single number would mislead. The output is an estimate, not a quote or a guarantee. Google's Firebase pricing page is the authority. Firemap's own plan pricing is separate from what Google bills you for Firestore.
Frequently asked
Is the Firestore free tier daily or monthly?▾
Operations are a daily allowance: 50,000 document reads, 20,000 writes and 20,000 deletes every day, resetting at midnight US Pacific time. Storage is different — it is a standing 1 GB allowance, not a daily one. This is why the calculator subtracts the free quota per day before multiplying by 30, rather than subtracting it once from your monthly total.
How much does Firestore cost per 100,000 reads?▾
$0.06 per 100,000 document reads on the Blaze plan. Writes are $0.18 per 100,000, deletes are $0.02 per 100,000, and stored data is $0.18 per GB per month. These rates are for a US multi-region and vary by region, so confirm against Google's official pricing page.
Why is my Firestore bill higher than my query count suggests?▾
Firestore charges per document returned, not per query. One query that returns 500 documents is 500 reads. Real-time listeners charge one read for every document in the initial snapshot and one more for each document that changes afterwards. Every exists() or get() call inside your security rules is also billed as a read.
Does the calculator include network egress?▾
No. Egress is free between Firestore and Google Cloud services in the same region, and otherwise depends on the destination region — roughly $0.01 per GB within the US and considerably more for some international destinations. Because the correct rate depends entirely on where your traffic goes, we left it out rather than guess and inflate your estimate.
Is this estimate accurate enough to budget against?▾
Treat it as a planning estimate, not a quote. It models the three operation types plus storage, which is the bulk of most Firestore bills, but it excludes egress, Cloud Functions invocations, and other Firebase products. Rates also change over time. Use the Firebase Console usage tab and Google Cloud budget alerts for authoritative numbers.
Does denormalizing my data make Firestore cheaper?▾
Usually yes, because reads outnumber writes in most applications and denormalization converts many reads into a handful of extra writes. Writes cost three times as much as reads per operation, so the trade only pays off when the read savings are large — which they normally are for feed, list and dashboard screens read far more often than they are written.
Your Firestore bill is a schema decision.
Design your collections visually, declare which fields to denormalize, and let Firemap generate the sync functions, types, rules and indexes.