# Cost and Performance Control — Firebase

Source: https://www.skillbyai.com/en/firebase/pr-cost

> Reads, listeners, indexes and budgets.

## Where the bill comes from

Firestore bills mainly per document **read, write and delete**, plus storage and network; prices, free quotas and plan names change, so check the docs. Reads add up quickly: a listener on a large query, a page that re-fetches on every render, or an admin screen that loads a whole collection. Controls: `limit()` every query, paginate, scope listeners and unsubscribe, cache stable data, denormalise to avoid fan-out reads, use aggregation queries for counts, and remove unused composite indexes (index entries consume storage and slow writes). Set **budget alerts** in Google Cloud billing; note that alerts notify rather than cap spending.

## A cost review list

Questions for each screen and function.

```text
- Does every query have a limit and pagination?
- Which listeners are open, and are they unsubscribed on navigation?
- Is any screen loading a whole collection to compute a count or a total?
- Are counters maintained by triggers or aggregation queries instead?
- Do triggers cause write loops (a function updating the doc that triggers it)?
- Are composite indexes in firestore.indexes.json all still used?
- Is there a TTL policy or scheduled clean-up for temporary data?
- Are budget alerts configured, and who receives them?
- Does the usage dashboard match expectations after each release?
```

## Watch for trigger loops

A Firestore trigger that writes to the document that fired it can call itself repeatedly. Guard with a condition or write to a different document.

**Quiz:** What is the main billing unit to watch in Firestore client code?

- [x] Document reads, writes and deletes
- [ ] Lines of JavaScript shipped
- [ ] Number of collections
- [ ] Length of field names only

*Answer:* Document reads, writes and deletes. Query design drives read counts.