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.
Gremlin API: Graph features and capabilities using Gremlin 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.
Built-in Apache Spark: Features related to built-in Apache Spark in Azure Cosmos DB.
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.
-
Be able to do partial updates on document
Allow to push only values for some fields of a document and not need to read the whole document and save it to documentDB.
4,310 votesWork on this feature has started. Will update here when this becomes generally available.
Thank you for your suggestion and votes.
-
Add Group By support for Aggregate Functions
We're really happy about the new aggregate functions that recently were announced. But without Group By support they fall short and will leave many disappointed. Please add Group By support as well.
2,831 votesAzure Cosmos DB now supports GROUP BY queries! With GROUP BY, you can run queries that group your results according to the values of one or more specified properties. This feature is currently supported in Data Explorer, JavaScript SDK 3.4, and .NET SDK 3.3. Support for other SDKs will be available later this year.
-
Support cross-document joins
I have a many-to-many scenario that requires something like document-to-document joins.
In my app, users can "like" posts. That's three "tables" or entity sets. One each for users, likes and posts. I can't put the likes inside of either the users or the posts entities as sub-documents because there could be thousands of them. Even with 256KB documents I'd run out of room pretty quickly. I need a way to quickly get the top 100 posts that a user liked (and continue to paginate from there). I also need to go the other way. I need to get all the…
1,643 votesFor applications that require cross document join, please consider the Gremlin API: https://docs.microsoft.com/en-us/azure/cosmos-db/create-graph-dotnet, which has primitives for joins, traversals, and other graph operations.
We are evaluating expanding the SQL grammar to support graph functionality, which will provide the ability to perform cross-document JOINs. Please upvote this item to help us prioritize this work.
-
Transaction support in client SDKs
it would be useful if documentdb transactions are supported in .net, rather than just storedprocs and triggers.
using trans = newtrans()
try
db.addsomething()
db.save() //ok
db.addother()
db.save() //fail
catch
trans.rollback
end try
end using1,278 votesThis is currently not on our roadmap. However, we will continue to review this item in the future as we prioritize future releases.
Thank you for your suggestion and for the comments.
-
Set based operations (INSERT, UPDATE, DELETE)
It would be nice to be able to update parts of documents, delete documents, and insert documents using set based operations, similar to SQL.
e.g.
UPDATE Users SET IsActive = 0 WHERE LastLogin < '2010-01-01'
DELETE FROM Users WHERE LastLogin < '2009-01-01'
INSERT INTO table2 SELECT * FROM table1889 votesThere are multiple responses to this suggestion.
Support for SQL-like syntax for UPDATE, DELETE and INSERT INTO are not on our road map at this time.
However, the underlying functionality for an UPDATE, SET is essentially a PATCH. This functionality we are actively working on. See this User Voice item here to track for future updates. https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6693091-be-able-to-do-partial-updates-on-document
Thank you for your suggestion.
-
Implement LIKE keyword
Add support for the LIKE '%%' SQL keyword and associated functionality.
801 votesAzure Cosmos DB supports the CONTAINS, STARTSWITH, and ENDSWITH built-in functions which are equivalent to LIKE.
We are planning to add support for LIKE since this is a top requested item, but meanwhile, please use the other equivalent keywords.
-
Support Document Versioning
The ability to generate links to a previous version of a document would be a powerful addition DocumentDB that has many use cases.
In my case I need a self managed profile document that needs to be referenced at point in time to be tied to an event.
762 votesAzure Cosmos DB now provides the ability to access the change feed (https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed). A common pattern to implement eventing patterns is
1. Store every version/change as a separate item
2. Read the change feed to merge/consolidate changes and trigger appropriate actions downstream.You can also expire old versions using TTL: https://docs.microsoft.com/en-us/azure/cosmos-db/time-to-live
-
Add support for single entity retrieval instead of IEnumarable
Single \ First and so are currently not supported in Document DB
For example, the following code:
return client.CreateDocumentQuery<TEntity>(collection.SelfLink).SingleOrDefault(x => x.Id == id);
causes the error:
An exception of type 'Microsoft.Azure.Documents.Linq.DocumentQueryException' occurred in Microsoft.Azure.Documents.Client.dll but was not handled in user code
Additional information: Query expression is invalid, expression return type Entities.Models.Hierarchy is unsupported. Query must evaluate to IEnumerable.
496 votesThank you for your feedback. I have discussed this in more detail with our team.
You are correct the workaround suggested to use .AsEnumerable().FirstOrDefault(). should not be a recommended work around. This way results in materializing all documents on the client first before getting the 1st document, which is not very efficient and the exact opposite of what you are trying to achieve.
Instead we recommend you use Take(1).AsEnumerable() and then .First() or .Single() or .FirstOrDefault() for Single() and First(). Take(1) is translated to SELECT TOP 1 and is processed server-side so more efficient than the previous suggestion and is what you are trying to achieve.
As to the original ask. The support for these operations can be done, but this work is not prioritized against the other work we want to deliver. I will move this back as unplanned but please note this is on our roadmap.
Thanks again…
-
Add the ability to delete ALL data in a partition
In a partitioned collection, it would be useful to have the option delete all data with a given partitionId.
447 votesThis is not currently on our road map. However, we will look at this in our next feature review and will provide update on status.
Thank you.
-
Linq provider should respect JsonSerializerSettings ContractResolvers
JsonSerializerSettings are now supported when creating the client, as per https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/6422364-allow-me-to-set-jsonserializersettings
However, when using for example a CamelCasePropertyNamesContractResolver to store the data, the linq queries will fail if the properties on the POCO classes are Pascal case.
430 votesThis is currently not on our roadmap. However, we will continue to review this item in the future as we prioritize future releases.
Thank you for your suggestion.
-
Support ORDER BY on the ST_DISTANCE spatial function
Ordering results by the ST_DISTANCE spatial function is currently not supported.
382 votesThis item was incorrectly marked as started. Actual work on this item has been deferred but is still planned.
Will update when this work is started.
Thank you.
-
Make COUNT() aware of indexes
Queries with COUNT() or other aggregates are very expensive and all appear to be scan driven vs. index driven.
I have 50k documents in collection, each has "Type" property with string value. The indexing policy is default.
The following simple query consumes 615 RUs:
SELECT VALUE COUNT(1) FROM x WHERE x.Type ='Content'The result is 9738 records.
The query metrics are:
RetrievedDocumentCount: 9738
RetrievedDocumentSize: 69506571
OutputDocumentCount: 1
OutputDocumentSize: 53
IndexHitDocumentCount: 0
IndexHitRatio: 0So what we see is that database reads all "Contents" and than counts them. But it's enough to just count the index entries not to read all…
256 votesWe have started work on this feature. Will update here when this becomes generally available.
Thank you for your request and votes.
-
Execute a procedure when TTL expires
I would like to execute a procedure when TTL expires. For example, when TTL expires I would like to also delete some related records from Azure table storage.
173 votesWe plan to introduce support for tracking deletes in the change feed. Using this capability, you can integrate with Azure Functions or another event processing system to perform operations like execute procedure or call other services programmatically.
-
Support multiple collections in stored procedures
Currently CosmosDB Stored procedures only allow access to a SINGLE collection (because they seem to be scoped to collections rather than to the database), via getContext() :
var collection = getContext().getCollection();
But any "useful" / "real-life" application using ComosDB will typically have to interact with more than one collection. For example, it is currently IMPOSSIBLE to insert documents into two distinct collections within a database using a single stored procedure -- a VERY SERIOUS drawback / limitation.
I would propose that stored procedures be scoped to the database level and then we would be allowed to do something like:
var…
159 votesThis is currently not on our roadmap but will revisit this in future planning cycles.
Thank you for your suggestion.
-
Support case insensitive indexing
Order by returns lowercase characters before uppercase characters.
x
y
z
A
B
CI know you can work around this by storing an all lower or all upper case version of the string you want to query by on your object but over time and scale that does add to your RU usage
159 votesWork for this feature is now planned. Will update here when work on this feature starts and when it becomes generally available.
Thank you.
-
Add DateTimeOffset support
The DocumentDb engine should be able to recognize and properly order DateTimeOffset serialized fields.
151 votesThis feature is now on our roadmap. There is no ETA for when this feature will become available but we will update here when work on this feature has started.
Thank you for your suggestion.
-
Order By Null Handling
Currently if you do an order by on a nullable value, the documents are not returned at all. Please add functionality similiar to Application Insights where you can specify if the documents with the null value appear at the beginning or end of the sort.
126 votesThis feature was mistakenly marked as having been started. This feature is still in plan and will be started in our next cycle. Will update when work starts and when it becomes generally available.
Thank you.
-
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…
113 votesThank 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.
-
Support OrderBy and OrderByDescending in Nested Arrays
For example in a document structure such as:
{
"id": "some id",
"things": [{ "value": "5" },
{ "value": "2" },
{ "value: "7" }]
}It would be great to be able to do something like:
queryable.Select(x => x.Things.OrderByDescending(y => y.Value)).AsEnumerable.FirstOrDefault();
90 votesThis is something we have on our backlog and eventually plan to implement this but it is not on our short-term plan. Will mark this as under review for now as we will continue to review the comments and votes on this issue as we revisit feedback.
Thanks for your request.
-
Compress stored data
Please compress data in place for more efficient use of storage.
For example, I recently exported the entire dataset from a collection and gathered the following stats:
DocumentDB Data Storage: 627 MiB (including hidden fields and other overhead I assume, but not Indexes)
Exported JSON: 461.72 MiB
Compressed JSON: 47MiBSo potentially a 10x saving in data storage size.
62 votesWe’re evaluating more compressed storage formats. Meanwhile, please consider using a client-side compression library for encoding fields/JSON fragments that are not used for querying.
- Don't see your idea?