I have read in the documentation that I'm being charged for the amount of the requests I'm making to read, write or update documents. I have also read that reading a collection is priced the same as a reading a document ("For queries other than document reads, such as a request for a list of collection IDs, you are billed for one document read."), correct me if I'm wrong.
My question is: Does reading a collection with a big amount of documents in it (let's say - 10,000 documents) is priced the same as reading one with 10?
I'd like to get some explaination about it...
It depends on what you mean by "reading a collection", but for most people this means "querying a bunch of documents from a collection". And the answer is that the pricing generally depends on the number of documents retrieved.
To oversimplify things just a bit:
If you have a collection of 10 employees and you run a collection("employees").get() call, you will get back 10 employee documents, and be charged for 10 reads.
If you have a collection of 10,000 employees and you run a collection("employees").get() call, you will get back 10,000 employees, and be charged for 10,000 reads.
If you have a collection of 10,000 employees and you run a collection("employees").get().limit(10) call, you will get back 10 employees, and be charged for 10 reads.
If you have a collection of 10,000 employees, 4 of which are named "Courtney" and you run a collection("employees").where("first_name", "==", "Courtney") call, you will get back 4 employees and be charged for 4 reads.
Related
Get 5 documents from users/ or from users/friends/Mike/sister/Jessica/rabbit... is the same amount of reads on the DB?
I mean, since I need to access to more locations will this increment the amount of reads or it depends only from how many documents I get from the collection?
You are charged only for documents that are returned to the client as a result of query, not for all the documents in the collection. If you want to limit your costs, you should also place a limit on the number of documents that the query can receive.
I have a question about Reads/Write in a Firestore DB.
The scenario is:
I have a Collection "City" (for example 20 Cities) and it has a subcollection "Restaurants" (e.g 500 restaurants):
Now is my question: When I want to get all Restaurant in a City, how many reads would Firestore bill? 500?
And when I want to add a Restaurant: Would it only need 1 write to add this document to the subcollection?
As Andres said: you are charged for document reads and writes. It doesn't matter what collection or subcollection the document comes from, each time the server reads a document on your behalf, you're charged for that document read.
So if you read 500 restaurant documents out of the subcollection of a city, you'll be charged for 500 document reads. If you add a single document to that subcollection, you're charged for a single document write.
If you regularly find yourself reading the same set of documents (e.g. the same 500 restaurants for all users in that city), consider creating a data model that reduces the number of documents you need to read. For example: you'll probably need a subset of the information from each restaurant, so you could extract that for all restaurants in the city into a "top restaurants list" document. This type of data duplication is quite normal in NoSQL databases, and key to keeping great performance with a reasonable cost.
Also see:
Getting to know Cloud Firestore, which covers this and many more scenarios.
NoSQL data modeling, which covers general data modeling for all kinds of NoSQL databases.
This answer I gave earlier today: Maxing out document storage in Firestore
One document read/write always costs the same, it could be in a collection, or a subcollection, or a subcollection of a subcollection - or a sub of sub of sub... you got the idea :)
If I have 1000 documents and I run a query to find 3 documents that meet a certain condition, will that count as reading 1000 or 3 documents?
Document reads are the fundamental unit of billing in Firestore as they relate to queries. Individual queries are not a primary unit of billing, but each query will be billed.
You will be billed for all the documents matched by a query, as those documents will be read and sent to the client. If your query matches no documents, then there is no billing. If your collection has 1000 documents, but your query returns 3 documents, you are charged 3 reads, not 1000.
The exception is that queries that return no documents are billed for a single document read. This means every query incurs a cost of at least one document read, no matter the results. If your query spans multiple requests (because of paging), you are billed at least one document read per request.
Please consult the documentation for Firestore billing to get more detailed information.
As per your query If you are fetching all documents at once on the client end and running your criteria search it will be counted as a single query.
However, if you use the query method of Firestore it will be also counted as a single query.
Note:
Don't have references yet, I am telling through the personal experience.
On Firestore I have a social app that stores each user as a document, and queries based on users within a certain distance.
If a user launched the app and had 1,000 users within 50 miles for example, would I be charged for 1000 reads for downloading all nearby profiles? That seems like it would be hyper expensive if I got charged that much every time a user queried nearby users. Is there a cheaper way to do this?
As far as I know, if your query returns 1 document, you'll be charged 1 read. If your query returns 1000 documents, you'll be charged 1000 reads.
I'm not sure how your app might look like, I'd rather re-structure fetching process. For instance, I'd rather not fetch the entire 1000 users at once.
Instead, the way of getting a fresh set of 10 or 20 group of nearby users whenever a person wants to see new users seems much better to me.
Hope this helps you.
Note: Be aware that your queries won't get any extra charges for having supplementary documents in a collection that are unread.
Have a look at Managing large result sets which help you manage queries that return a large number of results.
You can use Realtime Database as an alternative. It seems cheaper than Firestore. No document read. 10 GB is free and it means 200 million chat messages.
I use Blaze plan and i only pay for Firestore Reads. I plan to migrate some tables to old Realtime Database. I have 10.000+ users. I just show a calendar & dining menu to them from Firestore. I don't want to pay for such simple things.
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.
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.