Sub-collections for multi-tenant applications
In a multi tenant environment it is absolutely essential to limit results only to documents that belong to the current tenant. Adding a tenant name property to every document is not good enough because developers must ALWAYS remember to filter queries by that property. If they forget to do that the results can be devastating. It is also not possible to prevent that with tests.
To use a separate collection for each tenant is too expensive with the current pricing structure.
Please enable a possibility to add sub-collections that would act as a query boundary. They should also be a security boundary.
Moving this to declined. This request does not make sense with Cosmos DB as a partitioned data store.
I have a suggestion for this case. If you make the tenant name or id the partition key, then you would be forced to provide it because otherwise you would be running a cross-partition query, which you need to enable explicitly in the request. It doesn't offer a security boundary though, and I'm not sure if tenant id is a proper partition key for you.
Peter Lea commented
A lot of service providers would kill for this option. Currently we can't consider moving to cosmos because the risk co-locating tenant data is too high.
Yes, this would be great for development as well; I'm on Mac so can't run the docker container for document db.
Agreed that the current pricing structure is not granular enough for multi-tenant SaaS product. Per-collection would be fine if smaller, auto-scaling collection tiers were available. Start cheap, autoscale and pay-for-what-you-use. Just like most other Azure products.
Tom Tucker commented
We also need Sub-collections for MongoDB support. Mongo creates a new collection for each C# Type. Its too expensive to have that many collections.
Tom Tucker commented
I heard this was in the works. Can we get an update?
Andrew Liu commented
Many document databases treat "collections" similar to logical namespaces... This is useful for organizing different entity types in to different "collections" or namespaces.
DocumentDB treats "collections" as billable partitions, that which serve as the boundary for queries and transactions (yay multi-record transactions). The guidance suggests that users should store multiple entity types within a single collection… and annotate their JSON documents with a “type” property to help differentiate entity types when performing queries.
It would be nice to have logical namespace support. This may help solve the confusion surrounding “Collections != Tables”.