How many Firestore reads when listening to a collection after changing one item?

Question

Suppose I have a Firestore collection containing 10 items, and my app listens to a snapshot of that collection to get realtime updates, showing the results in a list view.

If I update one document inside that collection, a new snapshot will be emitted, so I can rebuild the list view.

But how many reads will take place?

Do I get 10 additional reads since the entire list view gets rebuilt (as I have a listener to the entire collection)?

Or is the Firebase SDK smart enough to figure out that only one document has changed and compute the new snapshot by taking the diff from the previous (cached?) one, resulting in one read only?

This is what the documentation says in this regard:

Listening to query results

Cloud Firestore allows you to listen to the results of a query and get realtime updates when the query results change.

When you listen to the results of a query, you are charged for a read each time a document in the result set is added or updated. You are also charged for a read when a document is removed from the result set because the document has changed. (In contrast, when a document is deleted, you are not charged for a read.)

My interpretation is that if I do this:

collectionRef.snapshots().listen((event) { ... });

then I should get 1 read per change.

But what if I use collectionRef.snapshots() as a stream to rebuild the UI (without an explicit listener)? Will this result in 1 read or N reads?

This was originally marked as duplicate of this . But the question is different as I'm asking about listening to a parent collection when a document changes (not listening to the document itself).

Answer 1

You will only have one read for your scenario, but after 30 minutes you will be charged for 10 reads and then after another 30 minutes, you will be charged for another 10 reads and so on...

I don't know why Cloud Firestore charges to reread the entire collection after 30 minutes. The data is already in the local cache. It should only need to read the changes since the last listener was active.