26

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...

Tal Barda
  • 4,067
  • 10
  • 28
  • 53

1 Answers1

65

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.

Todd Kerpelman
  • 16,875
  • 4
  • 42
  • 40
  • 4
    Is it just me or is this pricing model 100x more expensive than the previous Realtime Database? With Realtime Database querying a what is now considered a collection was considered a single read. I'd love to switch to Firestore for its better querying capabilities, but when my collections have thousands of documents I'll exceed the quotas very quickly. – Jared Jan 06 '18 at 01:54
  • 5
    Not necessarily. The Realtime Database primarily charges based on bandwidth size, while Cloud Firestore primarily charges based on the number of reads. The Realtime Database is usually more cost effective when you're dealing with apps that have frequent updates of small amounts of data, while Cloud Firestore is usually more effective when you're dealing with documents of larger chunks. Either way, though, you should really look at paginating your queries for more cost effectiveness. – Todd Kerpelman Jan 10 '18 at 19:13
  • 2
    @ToddKerpelman The line `collection("employees").get().limit(10)` should be `collection("employees").limit(10).get()` – CopsOnRoad Oct 16 '18 at 09:10
  • That’s k you for the answer in this it makes sense, I have been looking at reducing my reads, I have 53 documents and when I’m testing I’m using 1,000 reads, in an hour, I even put all the data in each document into an array or dictionaries – Tony Merritt Jan 05 '20 at 14:16
  • 1
    What about sub collections for instance `collection("/users/applications").where("first_name", "==", "Courtney")` ? – Ahmad Alkhatib Mar 25 '20 at 11:25