Are there any inherent performance advantages to subcollections or is it just structural?

[Kevin Burton]

I'm still trying to wrap my head around subcollections and why I would use these instead of just an ID on documents for the category.

For example the docs talk about chat rooms.

As subcollections you could have:

/rooms/roomA/messages

But you could also just have 

/rooms 

and each messsage would have a room_id of 'a'.

Seems like the same functionality would be supported. Just instead of using the path you would use the room_id

The only advantage listed that I can really see is:

"Advantages: As your lists grow, the size of the parent document doesn't change. You also get full query capabilities on subcollections."

... but why would that matter ?  They're not materialized views right?  Since I can't just drop the whole subcollection and there wouldn't be a performance increase.

I think I would prefer everything flat if there's no major advantage.

I mean I guess from an API perspective it's kind of cool that cloud storage and firestore would use the same path.  But that's mostly semantic.

[Thomas Gangsøy]

I have a web based pwa. Using angularfire2 with offline persistence. And have the structure /users/userid/maincollection/subcollection

And the subcollection in some cases have thousand of small documents per main document. 

What i have found is that on android and/or chrome for android, is that when the subcollections have been cached locally, the initial query for the maincollection can be really slow after app start. I have not had this issue on chrome/windows or iOS.

Not sure why, but i am looking into moving to a flat structure to remedy this. Not confirmed it will solve it, but i have a strong feeling it will.

Just something to think about if you have a similar use case.

[Kato Richardson]

Subcollections shouldn't affect performance for Firestore (RTDB is a different story). Performance in Firestore is mostly a function of the number of queries and byte count downloaded per query, but not whether the docs are stored as subcollections or in flat structures.

As I understand things, and my knowledge here is a few months out of date, subcollections don't currently make any big difference in performance or function, but may have some strong advantages as we continue to add better querying capabilities and security rules improvements in the future.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/bcf7d2b8-af7f-4030-af78-21f75d89b1e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Samuel Stern]

Hey all,

From a backend perspective, there's no performance difference with subcollections.  Your query performance will still scale with the number of results, no matter how deep the parent is.

Here are some current considerations:

• You can't currently query across subcollections, but this feature is planned for the future.  When it is launched, it should make subcollections significantly more useful.
• If you use root-level collections for everything, you're likely to have more where() clauses in your queries which means more compound index management if you're also using order/range clauses.
• Until we improve the indexing in the client libraries, subcollection queries may perform better offline than root-level collection queries since we likely have to scan fewer documents.  We are committed to fixing this as well.

- Sam

--