In my application there will be users (tens/hundreds). Each user will have many documents of the same type(typeA). I will need to read all these documents for a current user. I plan to use the following option:

root collection: typeACollection
    |
nested collections for users: user1Collection, user2Collection, user3Collection ....
    |
all documents for a specific user

An alternative to this solution is to create a separate root collection for each user and store documents of this type in it. But I do not like this solution - there will be a "not clear" structure.

user1typeACollection, user2typeACollection, user3typeACollection ....

your opinion which of the options is preferable (performance/price) - first or second?

CodePudding user response：

There is no singular best structure here, it all depends on the use-cases of your app.

The performance of a read operation in Firestore purely depends on the amount of data retrieved, and not on the size of the database. So it makes no difference if you read 20 user documents from a collection of 100 documents in total, or if there are 100 million documents in there - the performance will be the same.

What does make a marginal difference is the number of API calls you need to make. So loading 20 user documents with 20 cals will be slower than loading them with 1 call. But if you use a single collection group query to load the documents from multiple collections of the same name, that's the same performance again - as you're loading 20 documents with a single API call.

The cost is also going to be the same, as you pay for the number of documents read and the bandwidth consumed by those documents, which is the same in these scenarios.

I highly recommend watching the Getting to know Cloud Firestore video series to learn more about data modeling considerations and pricing when using Firestore.