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 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.
-
Support Gremlin Bytecode to enable the fluent API of Gremlin.NET
Azure Cosmos DB Graph API doesn't support Gremlin Bytecode. Therefor it is not possible to use the fluent traversal API of Gremlin.NET.
Within the Azure Cosmos DB Graph .NET API (https://docs.microsoft.com/en-us/azure/cosmos-db/graph-sdk-dotnet) it is recommended to use Gremlin.NET. So it would be really nice if all features of Gremlin.NET would be supported.
See also the idea of a "better type-safe APIs fro Gremlin" (https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/19340761-better-type-safe-apis-for-gremlin) within the Graph API feedback.
1,006 votesHello. Our apologies for the delay in an update here.
We are actively working on this and have a new ETA of Q2 2021.
Thanks for your patience.
-
Support Cypher as a query language for Graph data
Add Cyhper (see http://www.opencypher.org/) as a language to query graph databases. Cypher is a human readable query languages to easily access a graph database.
648 votesThis is currently not on our road map. However, we will review this item in the future as we prioritize future releases.
-
Implement a graphql provider
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.
370 votesApologies for the confusion on our part.
This is currently not on our roadmap. However, we will review this item in the future as we prioritize future releases.
Thanks for your suggestion.
-
Gremlin queries from stored procedures
It would be nice to have the ability to execute Gremlin queries against the Graph API from a stored procedure. Ideally, this would also enable transactions.
180 votesMoving this back to unplanned as this has been taken off our roadmap for Gremlin going forward.
-
Support for W3C SPARQL as a query language
SPARQL is a mature W3C standard for querying and updating graph-like data with well defined semantics and rich query capabilities.
153 votesWe don’t have any plans for SPARQL yet. We will keep this on our backlog and track user interest here as we prioritize upcoming work sprints.
Thanks.
-
Microsoft join and support GQL
I think it would be a great benefit for Cosmos DB to support the new movement to get to a single Graph Query Language. Microsoft joining this movement might help in rapid evolution and acceptance of such a language.
Taken from https://neo4j.com/blog/time-for-single-property-graph-query-language/:
The time has come to create a single, unified property graph query language.
Different languages for different products help no one. We’ve heard from the graph community that a common query language would be powerful: more developers with transferable expertise; portable queries; solutions that leverage multiple graph options; and less vendor lock-in.
One language, one skill set.
…
99 votesSupport for this is not on our roadmap but will mark as unplanned and leave open for future consideration.
Thank you for your suggestion.
-
Unique indexes on Graph vertex/edge properties
I need to ensure global uniqueness for things like username/email/mobile number/etc. Since we no longer have traditional SQL, this capability is lacking. Allow me to define unique indexes so the write region has only one occurrence of a distinct value.
Ideally, this should also make FILTERED unique indexes possible.
90 votesWork for this feature has been started. Will update here when this feature becomes generally available.
Thank you.
-
Support for Graph API in Data Migration tool
Looking for a way to do backup/restore or manual export/import of a Cosmos DB graph using Graph API - or equivalent.
I want to be able to restore state of a database while developing and found that Data Migration tool can do what I want, but does not support Graph API.76 votesThis is currently not on our road map. But we will revisit this again in our next review.
Thank you for your feedback.
-
Support strategies on graph traversals
Currently, the graph traversal in Cosmos DB graph (usually referenced by 'g') does not support the 'withStrategies'-method that is normally part of a Tinkerpop implementation. 'withStrategies' allows e.g to enhance the traversal with custom vertex- and edge-filtering on every step (by a SubgraphStrategy).
73 votesThank you both for your feedback on this. We will put this under review and revert with an update after our next planning cycle.
Thanks again.
-
Improve range() step costs
Graph API is nice, however in its current state it is unusable for large data sets due to high RU costs.
We are trying to implement paging for retrieving large amounts of data, however RU cost is unacceptable. Query "g.V().range(0,100)" costs 63.11 RU, however "g.V().range(2000,2100)" costs 338.06 RU even though it is same amount of data. Higher values are even more expensive meaning it's impossible to retrieve high amount of data without scaling up throughput.61 votesWork for this feature has been started. Will update here when this feature becomes generally available.
Thank you.
-
[Gremlin] Paging Support
Please add paging support for Cosmos Graph DB via the Gremlin API. Traversing the whole graph for a large set of vertices can be very expensive. Paging would allow better efficiency when targeting a subset of a large set of vertices.
57 votes -
add spatial support to Graph API
Enable the same support for spatial queries that exists for DocumentDb for graph elements. Similar to Neo4j Spatial.
49 votesThis is not in the Tinkerpop specification. We have no plans to add support to this just yet.
We will revisit this in the future however.
Thank you for you feedback.
-
CosmosDB Graph API should support array types inside Gremlin properties
Currently, the CosmosDB Graph API does not support array types inside of Gremlin properties. This forces users to rebuild their graph models to match what the Graph API requires. The CosmosDB Graph API should support array types inside of Gremlin properties.
46 votesWe’ve evaluated this request and at this time we are deferring this from our road map. Will leave this as open so we can consider this in the future.
Thanks.
-
Support Math functions in the graph
simple arthimatic (like computing %s) have to be done after extracting the data. pl support math step
45 votesWe are reviewing adding this capability. There is no ETA on if or when it will get on our roadmap but will update here when status changes.
Thank you for your suggestion.
-
Use a domain ontology (RDF/OWL) as a scheme in Graph DB?
In Cosmos Graph DB, I would like to be able to import a domain ontology (RDF/OWL) as a scheme to model data.
40 votesThanks Marc for your suggestion. This would require onboarding an entirely new API and is not currently on our roadmap.
Marking as unplanned.
Thanks!
-
Support multiple labels on vertices and allow searching by one of those labels
In order to represent inheritance in the graph DB, it is useful to have multiple labels on vertices and to be able to search by one of them, e.g.:
V1 labels = "human | man"
V2 labels = "human | woman"a query for all "human" returns both V1 and V2,
whereas a query for all "man" returns V1 only.Currently, this is possible in Neo4j:
https://tinkerpop.apache.org/docs/current/reference/#multilabel29 votes -
Gremlin Graph: Add support for array values in group() and groupCount()
You should be able to group by an array of values. it is perfectly valid to do a group() or groupCount() like so:
g.V().groupCount().by(values('id','name').fold())
Other Graphs implementing Gremlin will give you a result, while CosmosDB fails with:
"Unexpected Error: Cannot resolve object to a primitive value."
23 votesWe have reviewed this request and at this time this is not on our road map.
Will leave this open and review this in upcoming cycles for our road map.
Thanks.
-
To be upto date version of TinkerPop in Azure Cosmos Graph DB
Apache TinkerPop Graph released v3.4.2 on 28th May 2019, but it seems that Azure Cosmos DB graph is still supporting the v3.2 which was released a year back from today. Azure Cosmos Graph DB should be upto date to support the latest version of Apache TinkerPop Graph.
TinkerPop v3.4 supports various features like having support of min and max operations on comparable like string.
22 votesHello and thanks for your request. We support 3.4 from a driver and connectivity perspective but there are a number of features we haven’t implemented such as min and max on non-decimal values.
These are currently on our backlog to implement so will mark this as unplanned for now which will keep this request open. When this moves off of our backlog we will mark this as planned and update you here.
Thank you.
-
Allow shortestPath and sum steps
I want to make traversals finding the shortest path between one or more vertices. I need to be able to use shortestPath step or at least have sum step to sum up the edge weights to accomplish this.
22 votesAt this time this feature is not on our road map. We will leave this marked as unplanned for now and will revisit this in upcoming cycles and will update here if this changes.
Thank you for your suggestion and votes.
-
Support for schemas (full, mixed and none)
Support schema-full and schema-mixed modes like OrientDB. This way one can design a graph with vertex and edge classes. This is extremely useful when modelling known domains and removes all burden to do this in code.
21 votesCosmos DB is intended to be a schemaless database so we don’t support schemas in general. Support for this is not on our roadmap but will mark as unplanned and leave open for future consideration.
Thanks for your suggestion.
- Don't see your idea?