Firestore costs out of control? 10 ways to cut your bill in half

Where the money goes

Firestore charges for document reads, writes, deletes and stored data, plus a small egress fee. For almost every app over $50/month, the bill is dominated by reads. If you only have time to optimize one thing, optimize reads.

1. Cache aggressively on the client

The Firestore SDK has a built-in offline cache. Enable persistence and most repeat reads become free. For web apps using React Query or SWR, set a stale time that matches your data's freshness needs. A five-second cache on a dashboard can cut reads by 80%.

2. Use real-time listeners instead of polling

A listener costs one read per changed document, not one read per poll interval. If you have a screen that refreshes every 10 seconds and the data changes every 10 minutes, switching to a listener saves 59 reads per minute per user.

3. Denormalize for your hottest reads

If 80% of your reads need a username and avatar, copy them onto the parent document instead of looking them up every time. Yes, you'll write more on updates. Updates are 10-100x rarer than reads in most apps.

4. Paginate with limits, not full collection reads

Always pair queries with .limit(). The number of teams who write collection.get() and then slice client-side is alarming. Each row is a read.

5. Audit your listeners on unmount

Forgotten listeners are the single most common cause of mysterious cost spikes. Every navigation that leaves a listener attached doubles your read rate. Use the Firestore usage tab to spot the screens with the highest read-per-user ratio.

6. Use aggregation queries for counts

Firestore added count(), sum() and average() aggregation queries. A count() is one read regardless of how many documents it counts. Replace any 'fetch all and call .length' with count().

7. Cap document size

A 500 KB document costs the same to read as a 1 KB one, but it eats your egress and your client memory. Split large documents into subcollections so you only fetch what you render.

8. Batch writes

WriteBatch and Transaction count each write individually for billing, but they save on round-trip latency and reduce the chance of partial failures. The cost win is small; the reliability win is large.

9. Delete what you don't need

Storage is cheap until you have a few hundred GB of logs that nobody reads. Add a TTL policy on Firestore collections that hold ephemeral data; Google deletes them for free.

10. Audit with a GUI before you optimize

Half of cost optimization is finding the collection that's bigger than you thought. FireSheets shows document counts, size estimates and the actual field shapes per collection. The collections that surprise you are usually where the savings are.

A pragmatic order of operations

Turn on client caching. Add limits everywhere. Audit listeners. Denormalize the top-three hottest reads. Then look at storage. Most teams cut their bill in half before they get to step four.