I am considering using Google Cloud Firestore for a multi tenant application.
I have come accross this page which gives suggestions about scale: https://cloud.google.com/firestore/docs/best-practices#designing_for_scale
There is also this page showing limitations: https://cloud.google.com/firestore/quotas
I come up with this solution which may make better the performance and resilience of the application with minimum or no additional cost.
The solution: I can use different collections per each multi-tenant collection in the application like : products_1, orders_1, products_2, orders_2.
I want to use it because:
1- It will have better performance since I will have smaller tables/indexes. Otherwise in the long term, it may contain too many documents.
2- It is doable because the code interacts with collections with their names and I don't have to explicitly create collections. It doesn't seem like it is a big issue when compared to doing it with a relational database / ORM combination.
3- There is no limitations about how many collections I can create with different names.
So my question: Could any of my assumptions be incorrect such that it won't make any gain in terms of performance or it is not feasible to create infinite number of collections even if it's not documented.
Finally, can this approach create a possible maintenance trouble in long term which I cannot realise at the moment?
Thank you for your time.
Using separate collections to shard out clients is definitely a way to improve overall write throughput. But you don't need a naming convention for the collections.
Instead I'd consider creating a single top-level collection for all tenants/users and then have a subcollection for each tenant/user document. That way you have a separate subcollection for each tenant/user, but still have predictable collection names.