Understanding Firestore Pricing

If you actually have to pull an entire collection of 50k documents, the question you likely should be asking is how to properly structure a Firestore Database.

More than likely you need to filter these documents based on some criteria within them by using the query WHERE clause. Having each client device hold 50k documents locally sounds like poor database planning and possibly a security risk.

Each returned document from your query counts as 1 read. If there are no matches to your query, 1 read is charged. If there are 50k matches, there are 50k reads charged.

For example, you can retrieve the logged in user's document and be charged 1 read with something like:

db.collection('userList').where('uid', '==', clientUID)

Note: As of 10/2018 Firestore charges 6 cents (USD) per 100k reads after the first 50k/ day.

The free quota is for your entire project. So you're allowed 50.000 document reads under the entire project.

Reading 50K user profile documents will indeed use that free quota in one go.

Reading large numbers of documents is in general something you should try to prevent when using NoSQL databases.

The client apps that access Firestore should only read data that they're going to immediately show to the user. And there's no way you'll fit 50K users on a screen.

So more likely you have a case where you're aggregating over the user collection. E.g. things like:

• Count the number of users
• Count the number of users named Frank
• Calculate the average length of the user names

NoSQL databases are usually more limited in their query capabilities than traditional relational databases, because they focus on ensuring read-scalability. You'll frequently do extra work when something is written to the database, if in exchange you can get better performance when reading from the database.

For better performance you'll want to store these aggregation values in the database, and then update them whenever a user profile is written. So you'll have a "userCount", a document with "userCount for each unique username", and a "averageUsernameLength".

For an example of how to run such aggregation queries, see: https://firebase.google.com/docs/firestore/solutions/aggregation. For lower write volumes, you can also consider using Cloud Functions to update the counters.

Don't call all users in one go. You can limit your query to get a limited number of users. And when a user will scroll your query will get more users. And as no one is going to scroll fro 50k users so you can get rid of a bundle of cost. This is something like saving memory in case of recycle view.