Firestore Pricing: Calculate and Reduce Read Costs

Start with each repeated screen rather than monthly active users alone. Multiply documents loaded per screen by views per session, sessions per user, and monthly active users. Then add writes, deletes, stored data, and network transfer as separate inputs.

A feed that reads 20 posts, then fetches authors, comments, and counters separately can create far more reads than its page-view count suggests. Firestore also bills index entries read for some queries, so use Query Explain on high-volume queries instead of estimating only returned documents.

Store display-ready fields such as authorName, commentCount, likeCount, thumbnailUrl, and lastActivityAt on list documents when appropriate. This reduces repeated lookups. Put explicit limits on feeds, search results, and admin tables so each interaction has a predictable read ceiling.

Prefer cursors to offsets for pagination. Firestore charges reads for documents skipped by an offset, while a cursor can resume after the last visible document. For count(), sum(), and average() queries, include billed index-entry reads in the estimate rather than assuming every aggregation is free.

Realtime listeners are billed when documents enter or change in the result set. Reconnects can also repeat document and index reads, depending on offline persistence and disconnect duration. Keep listener queries narrow, unsubscribe when a screen is inactive, and measure reconnect behavior on mobile networks.

Compare the calculator's normal and high-traffic scenarios with actual usage in the Firestore console. If complex reporting, relational filters, frequent aggregations, or cross-entity admin dashboards dominate reads, compare Cloud SQL before committing to a Firestore-only model.