Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more here.

Azure Cosmos DB

Have feedback for Azure Cosmos DB product? Submit your idea here or upvote other ideas. All feedback is monitored and reviewed by the Azure Cosmos DB team. 

This site is for feature suggestions only. For technical questions or issues, please submit them to StackOverflow,where we and the community can better help you.

Please use the following categories when submitting your idea.

SQL API: Query language features, syntax using SQL API, indexing, any other core features in Azure Cosmos DB.

Gremlin API: Graph features and capabilities using Gremlin API.

Cassandra API: Features and capabilities using Cassandra API.

MongoDB API: Features and capabilities using MongoDB API.

Table API: Features and capabilities using Table API.

Etcd API: Features related to using etcd as a configuration store for Kubernetes.

Azure Synapse Link: Features related to Azure Cosmos DBanalytical store and Azure Synapse Analytics run-time support

Built-in Notebooks: Features related to built-in Notebooks in Azure Cosmos DB.

SDK: Features related to Azure Cosmos DB SDKs for SQL API.

Change Feed: Features related to Change Feed.

Management: All management features, backup/restore,monitoring, ARM, PowerShell and CLI.

Portal: All features for Azure Portal and Cosmos DB Explorer.

Emulator: Features related to the Azure Cosmos Emulator.

Other: Features not related to any other category.

Security:
Authentication, authorization,permissions and encryption features.

Monitoring:
Metrics, monitoring, alerts,and diagnostics features.

Server-side: Stored procedures, Triggers,and User-Defined Functions.

Managed Apache Cassandra: Featuresand capabilities related to Azure Managed Instance for Apache Cassandra.
  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Calculate RUs based on Output Document Size instead of Retrieved Document Size

    MongoAPI queries that use a projection like

    documents.find({ /*...*/ }, { name: 1 })

    can consume suprisingly high amount of RUs if the documents are big, but the query actually asks only for a small subset of information.
    Usually the whole point of a document based database is to store whole documents. With this cost model we are forced to split documents into multiple containers, which makes the whole design complex or switch to another database, just because costs are calculated this way.

    https://stackoverflow.com/questions/66320274/what-is-the-influence-on-cosmosdb-rus-when-using-projections-in-mongoapi-queries

    2 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  2. Azure Cosmos DB serverless a maximum limit of 5000 RU/s

    Are there a plans to increase
    These lead only to use Azure Cosmos DB serverless for Development and building prototypes

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  3. Spillover partitions

    For certain scenarios, such as storing the followers for a user, it's unfeasible to use any partition key other than the target user ID. This means there is a hard limit of around 60 million records that can be stored for that user. The request is to allow partition keys to span multiple logical partitions. If this is implemented as "all documents with a PK of Z and _ts greater than X go into logical partition Y", this may imply that the only index allowed on that container would be partition key and timestamp, as otherwise it might require cross-partition…

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  4. Consumption server less pricing with georeplication

    Please support georedundancy and multilocation-write also with consumption server less pricing ! Thanks.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  5. api for time series database

    If you could add api for time series database like InfluxDb in cosmos Db itself that would be great .

    Not sure if there is a dedicated time series database offering currently but for ease of use it would be better to have additional capabilities in existing products if possible .

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  6. Make serverless a true alternative to provisioned throughput

    According to your documentation, serverless is intended for small workloads and containers have a 50 GB storage limit. However, most of us would benefit from a true serverless system in mission-critical apps that only charges for the actual throughput usage. Please make serverless a first-class alternative.

    21 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  7. Azure CosmosDB Data Migration Tool

    Allow import as well as (existing) export of command line, make option to save command line at bottom of dialog to make it easier to see.

    65 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  8. Allow partition key to be changed to new items

    Request feature to update partition key to new value(item) because there should be chance users want to change partition key to new value after it spent some time since partition key is set. Like they will need to prepare for other queries with different partition key.
    under such situation, it will be annoying to migrate all data to newly created account.

    0 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  9. Database backend for django

    Would be great if a django db banckend in provided

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →

    Hello and thanks for your suggestion.

    We do not see much demand for Django with Cosmos DB so this is unlikely to make it on our roadmap.

    Will mark as unplanned for now and monitor if there is significant votes over time we will take another look at it.

    Thanks.

  10. Support Resource Partitions with more than 50GB storage

    The 50GB storage limitation has been restricting our ability to scale collections since day one.
    Almost every other competing tech that I am personally aware of on Azure allows you to pick the "node" storage size.
    Cosmos doesn't thus picking a one-size fits all strategy.
    I understand that this is a big architectural change for Cosmos (each resource partition has hidden replica sets that need to have matching storage limits etc) but I really believe this should be supported even if 1) I pay more to offset your costs and 2) it's only available with certain restrictions or limitations like…

    13 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →

    The size of our physical partitions is driven by the generation of hardware our fleet runs on. This was recently upgraded which allowed us to move to 50GB for physical partitions. We will certainly continue to upgrade our fleet and at some point we will offer increasing physical partition sizes.

    What is not on our roadmap is the option to select the size of physical storage. This is something however we will add to our backlog.

    Thanks.

  11. Provide staggered pricing on storage

    Right now, everything is charged at $0.25 per GB. This kind of pricing makes it impossible for companies to scale and stay on Cosmos DB. Please introduce volume pricing for storage.

    31 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  12. Could Cosmos DB support Firebase API?

    That would easy migration from Firebase.

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  13. Cosmos DB Capped Container

    Capped collection/contain is a collection that keeps given number or records at max. new records replace old ones if the collection is full.

    6 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  14. Ability to provide more than one PartitionKey per collection

    There are times when documents need to be queried by a secondary key field and the PartitionKey is not known.

    In order to avoid cross partition queries, the document needs to be stored twice - once with the primary PartitionKey and again with the secondary key field set as the PartitionKey.

    It'd be great if a secondary PartitionKey could be specified to allow for efficient querying without requiring saving the document multiple times.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →

    It is not possible to physically store data in a single partition with two partition keys. Physical partitions are functionally different computers.

    Services like DynamoDB which offer global secondary indexes do this by storing the data twice.

    To do this in Cosmos DB store the data in different collections and use Change Feed to keep them in sync. This provides the same functionality and provides additional flexibility in what data is shared between collections allowing for higher efficiency than simply copying all properties.

    Thanks.

  15. Ability to create dedicated containers with 100 RU/s

    I need to create 30 containers, but it becomes too expensive when I need to allocate 400 RU/s per container at minimum. If I use a shared database, then I cannot individually convert containers to dedicated containers in the future as my budget becomes better. I'd really like to see the ability to create 100 RU/s dedicated containers so that I don't have to deal with messy migration.

    56 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    4 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  16. Calculator for Mongo, Graph/Gremlin,Cassandra and Table

    Need calculator for Mongo, Graph/Gremlin,Cassandra and Table. Currently users face difficulties to estimate costs. They need to input data and query by themselves otherwise consumed RU cannot be known.

    Please consider implementing calculator for Mongo, Graph/Gremlin,Cassandra and Table.

    32 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  17. Move RU throughput allocation from Collections to Database Level and viceversa

    We have multiple databases with many collections and would like to move the throughput allocation from single collections to Database level without recreating it and migrating everything.

    184 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    9 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  18. Configure RU per region

    For a database/collection that is made available in several regions, make it possible to provision RU capacity independently in each region. Use case: Secondary backup region that exists only as an up-to-date mirror of data in case the primary becomes unavailable, not to offload read operations under normal operation. Currently this means provisioning unused RU capacity, at a high cost, in the secondary region.

    70 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →

    Hi Magnus. This is currently unplanned by us for our road map. Some context and feedback for you on this.

    First, to do the replication itself to the secondary region you need RU/s sufficient to support the request rates for the primary region itself. Replication and writing to the secondary region itself is not free so there needs to be sufficient throughput provisioned to do that.

    Second, for the secondary region to be able to function as the primary should a fail over occur, the replica region itself needs sufficient throughput to function as the primary.

    Thanks again for your suggestion. Will mark as unplanned for now in case circumstances ever do change.

  19. Implement a GraphQL Provider (repost)

    (Previous post with the same title was closed without giving the correct solution.)

    graphql {http://graphql.org/} is becoming increasingly adopted by front end frameworks (including mobile) for querying backend / API data.

    Rather than having to translate each graphql query into a DocumentDB client call it would be optimal and very powerful to issue the query directly.

    It would also provide enhanced query abilities over the existing REST approach.

    48 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →
  20. Pricing Granularity per Minute instead of per Hour

    It is buried in the FAQ;s on the pricing page. The current billing structure will take the largest RU offer in a given hour increment and that's what is charged for that hour. If you scale up to 1000RU's at 10:59 and down to 400 at 11:01, the billing for both hours will be @ 1000RU's. This makes scaling up and down harder to deal with and reason about. Can you evaluate changing the billing granularity down to the minute level in order to allow shorter bursts of scale up / down billed for the actual usage.

    42 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    5 comments  ·  Other  ·  Flag idea as inappropriate…  ·  Admin →

    We’ve recently announced a serverless model for Azure Cosmos DB – which we believe addresses use-cases with sparse but spiky throughput. Serverless enables billing based on a per consumed request unit basis – which goes 1 step further than managing provisioned throughput at a per minute granularity.

    We will continue to support the provisioned throughput model (along with autoscale) for use-cases that have high throughput utilization and/or require stronger guarantees w.r.t. availability and performance characteristics.

    For more information – please see: https://devblogs.microsoft.com/cosmosdb/serverless-preview/

← Previous 1
  • Don't see your idea?

Feedback and Knowledge Base