Cost and Performance Control

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.

- 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.

त्वरित जाँच: What is the main billing unit to watch in Firestore client code?

• Document reads, writes and deletes
• Lines of JavaScript shipped
• Number of collections
• Length of field names only