'Firebase: Cloud Firestore: listDocuments: doc read cost 1 or N? Possible alternative to Distributed Counter?

Building a social media app and confronting the 1write/doc/sec limit. Consequently, keeping vote data in the post document will not work at scale. I have read into "Distributed Counters", but the document read/write cost scales linearly. I have been exploring the firebase functions available and am interested in "listDocuments()", which return a List of DocumentReference's

Unfortunately, digging through the documentation I cannot determine if listDocument read cost is 1 or 1/doc in the collection.

My plan is to have two subcollections per post, vote1/vote2. This removes the write bottleneck at scale. To retrieve the vote count I would like to use the length of listDocuments() on each subcollection.

I know firebase has some neat indexing tricks, but I am also curious if this is an inefficient operation on the database. i.e. will the user notice a delay when retrieving the counts?



Solution 1:[1]

Unfortunately, digging through the documentation I cannot determine if listDocument read cost is 1 or 1/doc in the collection.

Calling the listDocuments API cost one document read per document that is returned by it.

Solution 2:[2]

Because there is some confusion around the read costs, especially with the listDocuments() function, i want to answer this question in more detail. The answer of @Frank van Puffelen is correct, you'll get charged per returned document.

The listDocuments() method: Reading the parameter description allready hints that the documents get read. https://firebase.google.com/docs/firestore/reference/rest/v1/projects.databases.documents/listDocuments

The return value: It stands out that you'll get an array of documents, not of their references. https://firebase.google.com/docs/firestore/reference/rest/v1/ListDocumentsResponse

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Frank van Puffelen
Solution 2 Yuki