Firestore pricing model case

Question

im trying to understand the firebase pricing model and I stumbled over this. https://firebase.google.com/docs/firestore/pricing

Queries other than document reads

For queries other than document reads, such as a request for a list of collection IDs, you are billed for one document read. If fetching the complete set of results requires more than one request (for example, if you are using pagination), you are billed once per request.*

Let's say Im fetching 10 profiles from a profiles collection (10.000 documents) randomly limit(10) it would cost me 10 reads.

return FirebaseFirestore.instance
    .collection('profiles')
    .limit(10)
    .get()
    .then(...)

Now I want to show my 10 results in the UI and I also want to show the clients a heart icon which is filled if the client liked the profile or not. I would fetch the user data and check if the user liked one of the 10 profiles. I already learned storing the user specific data in the same collection profiles doesn't make sense, lets say we are saving it in a users collection subcollection called profilelikes:

return FirebaseFirestore.instance
        .collection('users')
        .doc('userId')
        .collection('profilelikes')
        .get()
        .then((QuerySnapshot querySnapshot) => {
              querySnapshot.docs.forEach((doc) {
                if () {
                  // check if profiles from list matches userprofile document
                }
              })
            });

What does it mean for this case exactly? Lets say the user has 5000 documents inside the profilelikes Im searching in 5000 documents if 10 of them are matching or not. Let's say 2 of them are matching:

How many costs do we have here?

First Query: 10 reads because we have 10 results here Second Query: ???

Just a recommendation, if you don't want to fret over read/write counts stick with the Realtime Database because it has a much simpler billing structure. — Brian Burton
Thanks for the answer. i think in my case the realtime database doesnt make sense to me because it is deep not flat, since i have a lot and hierarchical data and the realtime data does the billing on bandwith amount it reads the whole tree even if i dont need it. real time database is good for simple data structure. Anyways it would be interesting if somebody could point out what happens to the provided case :) — Marcel Dz

Renaud Tarnec Renaud Tarnec · Accepted Answer · 2021-03-16T12:48:09

The chapter you point out in your question actually covers "queries other than document reads". For example with the Firestore REST API you can list the collection Ids, see here in the API doc. The same with the Admin SDKs, see for example the listCollections() method.

In your case, you are actually reading documents.

So the first query will cost 10 reads, "because we have 10 results" as you said.
The second query (collection('users').doc('userId').collection('profilelikes').get()) will cost 5000 reads since you are querying the entire (sub)collection which contains 5000 documents.

Conclusion: you should most probably adapt your data model (denormalization?) in order to avoid fetching an entire subcollection.

PS: It's worth noting the concept of minimum charge for document reads: "There is a minimum charge of one document read for each query that you perform, even if the query returns no results."

Firestore pricing model case

1 Answers