What are performance/billing trade-offs for firebase root collections vs subcollections within a collection

Question

I'm aware that root-level firebase collections are the most flexible and scaleable, and that sub collections cant be easily deleted. And that in terms of billing I'm aware that with firestore, its about total amount of data stored, db operations, and amount of data returned by a result set. But let's say Im debating between different database architecture approaches for an app that includes messages & conversations:

using Root level collections-only:

• Conversations-Collection Fields
  • members ( array of user refs)
  • lastReceivedTime
• Messages-Collection Fields
  • conversationId (conversation doc ref)
  • to (user ref)
  • from (user ref)
  • content
  • datetime

using a root collection for conversations and messages subcollection

• Conversations-Collection Fields
  • members ( array of user refs)
  • lastReceivedTime
  • Messages Subcollection
    • content
    • dateTime
    • from (user ref)

The collection & sub collection route seems simpler, but what are the Firebase performance/billing/operations pro's/cons of each approach?

Answer 1

According to the documentation for Firestore billing:

When you use Cloud Firestore, you are charged for the following:

• The number of reads, writes, and deletes that you perform.
• The amount of storage that your database uses, including overhead for metadata and indexes.
• The amount of network bandwidth that you use.

Unless you can show that your change in structure has any change in the way that any of these things are measured, then there is no significant change in your billing.

If all your queries still read, write, and delete the same number of documents, then the billing for point 1 will remain unchanged.

If all your documents still contain the same data, then the billing for point 2 will remain unchanged.

If the prior two assumptions still hold, then the network bandwidth to transfer everything is essentially the same, which means the billing for point 2 will remain unchanged.

There might be a few bytes of difference here and there due to the way that document paths might be stored and transferred. Assuming that longer document paths will incur a few more bytes of storage and bandwidth, then deeper collections might a bit more expensive. But in my opinion, if you're trying to optimize away a few bytes of data per documents, you should show that the difference in cost is actually worth your time. If you haven't already computed what the saving will be, then it's a premature optimization, and probably not worth the time. Do whatever saves you more time, so that you can get more done.