Developers have reported bills going from $10 to $4,976 overnight. This isn't a Firebase bug — it's a predictable consequence of architecture decisions that made sense in development but scale non-linearly in production. Here's every trap, explained with real numbers.
In Firebase, costs don't always scale linearly with your user count. A real-time listener that works beautifully with 10 users can consume 1,000× more operations when you have 1,000 users — because every new write fans out to every active listener. Budget alerts notify you after charges have already accrued. By the time an alert fires, you may already have a significant bill.
This is the single most common cause of unexpected Firebase bills. A real-time listener (`.onSnapshot()`) on a Firestore collection charges a read for every document in the collection scope each time Firestore delivers an update — even if only one document changed.
The fix: use targeted queries scoped to the minimum required documents.
// Listens to the whole collection
db.collection("posts")
.onSnapshot(snap => {
// Re-fires for EVERY change
// Reads ALL docs each time
});// Scope to user + recent only
db.collection("posts")
.where("userId", "==", userId)
.where("createdAt", ">", lastSeen)
.limit(20)
.onSnapshot(snap => {
// Minimal read surface
});The Firebase Realtime Database uses a different cost model to Firestore. It's charged per simultaneous connection and per GB of data transferred — not per read/write operation. For real-time chat or game apps with many concurrent users, this can escalate quickly.
| Metric | Spark limit | Blaze pricing |
|---|---|---|
| Simultaneous connections | 100 max | Unlimited (no per-connection charge) |
| Storage | 1 GB | $5 per GB / month |
| Download / bandwidth | 10 GB / month | $1 per GB |
The Realtime Database download cost trap: a live sports score or chat feed that pushes frequent small updates to thousands of simultaneous connections will generate substantial download bandwidth. At $1/GB, an app pushing 1 MB of data every 5 minutes to 1,000 users accumulates approximately 8.6 GB/day — well into paid territory.
Data leaving Google Cloud to the internet is charged at $0.12/GB after the first 10 GB/month (shared across your project). This catches many developers who don't think about "bandwidth" when using Firebase.
See the authentication pricing guide for full country rates. Summary: 15,000 SMS verifications to UK phone numbers at $0.04/SMS = $200/month beyond the 10,000 free tier. An app scaling in high-cost SMS regions can see significant unexpected auth costs.
This is the most psychologically dangerous cost trap: developers assume that setting a budget alert at $50 means they'll never be charged more than $50. That's not how it works.
To actually cap spending, you need Google Cloud budget controls with a Pub/Sub action configured to disable billing on the project when a threshold is reached. But here's the catch: disabling billing disables the entire project, including all free-tier services. There is no middle ground that limits usage without stopping the app. Your options are:
| # | Fix | Estimated cost impact |
|---|---|---|
| 1 | Enable Firestore offline persistence | High — eliminates re-reads of unchanged data on return visits |
| 2 | Replace collection listeners with targeted queries | Very high — can reduce reads by 10-100× |
| 3 | Add .limit() to all list queries | High — prevents full collection scans |
| 4 | Serve Cloud Storage files directly (not via Functions) | Medium — halves egress cost for file serving |
| 5 | Enable App Check for phone auth | Medium — blocks bot-triggered SMS verifications |
| 6 | Use test phone numbers in development | Low but guaranteed — eliminates development SMS costs entirely |
| 7 | Cache Firestore reads in component state or localStorage | High for read-heavy UIs — avoids re-fetching on re-renders |
| 8 | Paginate dashboard queries — never load >100 documents at once | High — keeps dashboard and admin tools from generating mass reads |
Honest assessment: Firebase's pricing is competitive and often cheaper than alternatives for most apps. The unpredictability problem is architectural, not structural — it comes from Firestore's per-operation model. For read-heavy apps where you can't implement effective caching, Supabase's flat-rate Pro plan ($25/month) is more predictable. AWS Amplify is generally more expensive but offers deeper AWS integration. See the Firebase vs Supabase comparison and the full alternatives guide for detailed cost comparisons.