Firestore: Performance of reading user-to-user relations

Question

Assume a typical messenger which allows its users to have other users as contacts. And two contacts share the same set of preferences.

I am unsure how to model that in Firestore concerning performance and elegance.

Option A

/ users
  - id
  - name

/friends
  - user1_id 
  - user2_id 
  - shared_preferences

To read the friends list user1 would query something along these lines:

friends.where( Filter.or ( user1_id == ID, user2_id == ID ) )

I am concerned with the performance, assuming that the app has a very large user base.

Option B

The other solution would be to store the friends list as a sub-collection:

/users
  - id
  - name
  /friends 
    - friend_user_id
    - shared_preferences

To read the friends list user1 would simply query the sub-collection:

/users/ID/friends

Reading the each users friends list would not be a performance issue.

But it would imply that whenever user1 modifies the shared_preferences, the same preferences have to be updated for user2. This could be done via a cloud function.

Question

I prefer Option A as this means no redundant data and no additional cloud functions to update that redundant data.

How problematic is running a WHERE-OR against a large dataset in Firebase?

Answer 1

How problematic is running a WHERE-OR against a large dataset in Firebase?

The query performance In Firestore depends on the number of documents you request and not on the number of documents you search. So the number of documents that exist in a collection is irrelevant. So it doesn't really matter if you search for 10 documents in a collection of 100 documents, or in a collection of 100 million documents, or even in a collection of 1 billion documents, the response time will always be the same.

Regarding the schema:

I prefer Option A as this means no redundant data and no additional cloud functions to update that redundant data.

It's up to you to decide which solution works best for your app but remember, denormalization is a quite common practice when it comes to NoSQL databases like Firestore. If you're new to the NoSQL database, this might sound a little weird, but believe me, it will help make your requests even cheaper.