Understanding Firestore Pricing

Question

Before creating a new app I wanna make sure I get the pricing model correct.

For example in a phonebook app, I have a collection called userList that has a list of users which are individual documents.

I have 50k users on my list, which means I have 50k documents in my collection.

If I were to get the userList collection it will read all 50k documents.

FireStore allows 50k document reads. Does that mean 50k document reads in total or 50k document read per document?

As in the example of my phonebook app if it is 50k document reads in total I will run out of the free limit in just one get call.

Answer 1

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.

Answer 2

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.