Right structure for Firebase for low cost and best readability

Question

I am migrating from Supabase to Firebase.

here is my current setup (example). In reality, it is a little big bigger with more attributes.

Now I am migrating the product data to Firebase Firestore. The main question is. Should I store sizes, and images in a subcollection from the product, so I need to read all subcollection when I fetch a product? Or should I just store sizes and images in the product itself? When I store it in the product there is a lot of data. And it is not so easy to see the data easily on the web of Firebase. But I only need to fetch once for all Data. The subcollection is for better readability and is easier to change.

In the same, I would ask for accounts. How to manage everything there. All referenced tables as subcollections or in the main document.

Answer 1

So I need to read all subcollections when I fetch a product. Or should I just store sizes and images in the product itself?

In my honest opinion, you should store all product data inside a single document. In this way, you'll save additional reads.

When I store it in the product there is a lot of data.

There will be no problem, as long as you stay below the maximum 1 Mib limitation.

The same I would ask for accounts. How to manage everything there.

The same as above.

However, please also note that there is no "perfect", "the best" or "the correct" solution for structuring a Cloud Firestore database.