Case Study
How hidden Firestore reads cost you real money
Developers often don't see the patterns that cause bills to spike until it's too late. This case study shows real patterns and how ReadMeter reveals them early.
At a Glance
- 240M reads/month → 96M reads/month
- $190/month read costs → $75/month
- 8 hours implementation time
- Immediate payback — savings in the first month
Situation
An admin platform for courses, resources, and exams. The team used Firebase for real-time data — standard for modern apps. They expected normal costs. Nothing unusual. Until the bill arrived.
The Problem
The bill doubled. 240M reads — and no idea which features caused it.
- • 240M monthly reads (up from ~120M)
- • $190/month in read costs alone
- • GCP showed totals — no feature breakdown
- • No caching — every page hit Firestore fresh
- • Same collections fetched multiple times per session
- • No read tracking — optimization was blind
Discovery
ReadMeter reveals what GCP hides. Toggle GlobalCache and switch pages — the widget shows reads and Read Sources in real time.
Simulate admin session: toggle GlobalCache and switch pages. With cache, users/resource data loads once — subsequent pages use it.
Dashboard
Direct Firestore — every visit triggers full read
Once they could see the pattern, the fix was obvious: cache the frequently accessed data instead of hitting Firestore on every page load.
Impact
- • GlobalCache — in-memory layer for users, courses, resources, exams
- • Moved dashboard, progress reports, exam charts, resource pages to cache
- • Optimized Cloud Functions: incremental updates + field selection
- • ~8 hours implementation time
Monthly reads
Monthly reads
| Metric | Before | After |
|---|---|---|
| Monthly reads | 240M | 96M (–60%) |
| Reads per admin session | ~12,000 | ~2,500 (–79%) |
| Cloud Function reads/day | ~50,000 | ~5,000 (–90%) |
Cost Impact
- Read costs: $190/month → $75/month
- 60% read reduction — savings visible in the first month
Lesson
What Developers Can Take Away
- 1Reads are the biggest cost driver — 67% of Firestore costs were reads
- 2Caching is highly effective — simple in-memory cache reduced reads by 80%
- 3Visibility is crucial — without tracking, optimization is blind
- 4Client-side filtering works — fetch once, filter many times
- 5Incremental updates scale — processing only changes reduces scheduled function costs
Best Practices
- 1. Always wrap Firestore calls with
trackRead() - 2. Use GlobalCache for collections accessed more than once per session
- 3. Implement cache invalidation on data mutations
- 4. Use
.select()to fetch only needed fields - 5. Prefer client-side filtering over multiple queries
- 6. Run full collection scans weekly, incremental daily
Mistakes to Avoid
- ✗ Fetching all users for simple role checks
- ✗ Querying the same collection from multiple components
- ✗ No cache expiration (stale data)
- ✗ No read tracking (blind optimization)
- ✗ Processing all documents in scheduled functions
How ReadMeter Helps
This team built custom read tracking to uncover their hidden patterns. ReadMeter gives you that visibility from day one — so you can see exactly where reads go, spot costly patterns early, and fix them before the bill explodes.
- See where your reads are going
- Get optimization suggestions
- Track savings in real-time
Appendix: Cost Breakdown
Monthly Firebase bill before optimization:
Cloud Firestore: $280 ├── Reads: $190 ├── Bandwidth: $48 ├── Zonal Backup: $36 ├── PITR Data: $2 ├── Bytes Stored: $2 ├── Writes: $1 └── Stored (No Free): $1 Hosting: $10 Cloud Storage: $2 Functions: $0.02
What ReadMeter Offers
- See exactly where your reads are going
- Get automated optimization suggestions
- Track savings in real-time
- Pay for itself in the first week
See your reads before your bill explodes
ReadMeter gives you development-time visibility into Firestore read patterns — so you can spot risky behavior early, like in this case study.
Get ReadMeter — $9 (one-time)