How can we improve Azure Cosmos DB?

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.

102 votes
Vote
Sign in
(thinking…)
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
Branko shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Thank you for your suggestion. This is not currently on our road map.

As suggested by others, customers are implementing this pattern using the same container with a partition key per tenant or a synthetic key with the tenant id and one or more other properties.

Will mark this as unplanned and leave open and will revisit this in future planning cycles.

Thank you for your suggestion and votes.

7 comments

Sign in
(thinking…)
Sign in with: oidc
Signed in as (Sign out)
Submitting...
  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Yes, this would be great for development as well; I'm on Mac so can't run the docker container for document db.

  • zmorris commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Andrew Liu commented  ·   ·  Flag as inappropriate

    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”.

Feedback and Knowledge Base