2

I am attempting to figure out a solid strategy for handling schema changes in Firestore. My thinking is that schema changes would often require reading and then writing to every document in a collection (or possibly documents in a different collection).

Here are my concerns:

  • I don't know how large the collection will be in the future. Will I hit any limitations on how many documents can be read in a single query?
  • My current plan is to run the schema change script from Cloud Build. Is it possible this will timeout?
  • What is the most efficient way to do the actual update? (e.g. read document, write update to document, repeat...)
  • Should I be using batched writes?

Also, feel free to tell me if you think this is the complete wrong approach to implementing schema changes, and suggest a better solution.

twiz
  • 9,041
  • 8
  • 52
  • 84

1 Answers1

1

I don't know how large the collection will be in the future. Will I hit any limitations on how many documents can be read in a single query?

If the number of documents gets too large to handle in a single query, you can start paginating the results.

My current plan is to run the schema change script from Cloud Build. Is it possible this will timeout?

That's impossible to say at this moment.

What is the most efficient way to do the actual update? (e.g. read document, write update to document, repeat...)

If you need the existing contents of a document to determine its new contents, then you'll indeed need to read it. If you don't need the existing contents, all you need is the path, and you can consider using the Node.js API to only retrieve the document IDs.

Should I be using batched writes?

Batched writes have no performance advantages. In fact, they're often slower than sending the individual update calls in parallel from your code.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • So do you know if there is any actual enforced limitation on the number of results from a query? Also, what is the benefit to only retrieving IDs? Is it faster/cheaper? – twiz Jul 14 '19 at 18:01