Firebase Pricing: What Is Free and What Generates a Bill

Firebase has two plans. Spark is free with hard limits — when you hit them, things stop working. Blaze is pay-as-you-go — it includes the same free allowance every month, and charges for what you use beyond it.

The counter-intuitive part: Blaze is usually the *safer* choice, because on Spark your app breaks when you hit a limit, while on Blaze it keeps running and costs a few pence. The risk on Blaze is not the normal case — it is the runaway loop.

The services that are free, permanently

These have no paid tier at all. Use them as much as you like.

• Cloud Messaging — push notifications, unlimited, on every platform.
• Crashlytics — crash reporting, unlimited.
• Google Analytics for Firebase — event tracking and reporting.
• Remote Config — feature flags and settings you can change without shipping an update.
• A/B Testing and Performance Monitoring.

If your app only uses these, Firebase costs nothing and always will.

The services that charge, and how

This is the part worth understanding properly, because each one meters something different.

Note the difference between the two databases. Firestore counts operations. Realtime Database counts bytes. That single distinction decides which is cheaper for your app, and it is covered properly in the Firestore vs Realtime Database guide.

The Firestore read, explained

This is the concept that causes the most surprise, so it is worth being exact.

One document returned equals one read. Size is irrelevant. A document with a single field costs the same as one with two hundred.

• A query returning 500 documents costs 500 reads.
• A live listener charges for the initial documents, then one read per document that changes.
• A query matching nothing costs a minimum of one read.
• Reading a document ten times costs ten reads, unless the local cache serves it.

The three patterns that cause surprise bills

1. 1

   The unbounded listener

   A realtime listener on a collection with no limit(). It works beautifully with 50 documents in development and charges you for 50,000 in production. Always bound your queries.

2. 2

   The recursive Cloud Function

   A function that writes to Firestore, triggered by writes to Firestore. It calls itself, forever, at machine speed. This is the single most expensive mistake in Firebase and it is easy to make by accident. Check that any function writing to a collection is not also listening to it.

3. 3

   The re-rendering query

   A query inside a React component without proper dependencies, firing on every render. Each render is a fresh set of reads. This is a client-side bug with a server-side invoice.

Why Cloud Functions require Blaze

Cloud Functions are not available on the free Spark plan. This catches people out, because Functions are how you do anything server-side in Firebase.

The reason is that functions can make outbound network requests, and Google will not let anonymous free accounts call arbitrary internet endpoints. Blaze includes a monthly free allowance of invocations, so a small app on Blaze frequently pays nothing for Functions — but a card must be on file.

Keeping the bill small

1. Set a budget alert immediately. Before your first deploy, not after your first invoice.
2. Paginate everything. limit() on every query, without exception.
3. Store counters, do not count. Reading 10,000 documents to display "10,000 users" costs 10,000 reads. Keep a counter document and update it.
4. Let the offline cache work. Firestore serves repeat reads from cache. Do not disable persistence without a reason.
5. Check function triggers for loops. Any function that writes to the collection it listens to needs a guard.
6. Watch egress. Serving large files from Cloud Storage to many users is bandwidth, and bandwidth is billed.

Roughly what to expect

A small app — a few thousand users, sensible pagination, no video — usually lands inside the free allowance or costs a few pounds a month.

Costs climb steeply when you have read-heavy dashboards, large media files, or Cloud Functions doing real work on every request. At that point Firestore's per-operation pricing is worth modelling properly against a conventional database.