I want to be able to create an Azure Cosmos Account that supports multiple APIs
Since Cosmos DB with the Mongo API does not support all Mongo commands, I would like to be able to configure Cosmos DB accounts to support multiple apis (e.g. Mongo and Sql/DocumentDB) as described here: https://stackoverflow.com/questions/44247726/is-there-a-way-to-configure-cosmosdb-to-use-both-the-sql-documentdb-and-mongod
Azure Cosmos DB is a multi-model database service, and therefore supports accessing the same underlying data using any/all APIs. We are however implementing some platform-level changes to make data access from different APIs seamless like supporting conversions between disparate type systems, and capabilities.
Yohan S. commented
Any update please?
Danny Shemesh commented
Hm - this doesn't seem to work anymore since the new mongo 3.6 wire protocol; I'm now getting 'Sql api is not supported for this database account', and have no ability to turn it on via az cli / powershell.
Is there any workaround ?
Russ Christensen commented
My scenario is I want to shift from Azure Table Storage to Cosmos DB using the Table API and then over time I want to convert the application slowly to use the more fully featured Document DB SQL API.
David Hernandez commented
This comment looks in contradiction with the one here: https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/19448422-i-want-to-be-able-to-create-an-azure-cosmos-accoun
"Azure Cosmos DB is a multi-model database service, and therefore supports accessing the same underlying data using any/all APIs."
Chris Pietschmann commented
Is there any update that can be made on the status of this? Or at least a description of what is currently supported and what's not?
This would be amazing. Having to create multiple resources for this kind of thing is both more expensive and painful.
Any update on that feature status? Any ETA when it will be in preview?
We're currently using several cosmos dbs via the graph api. We also use the document sdk to add more complex documents and then use gremlin to add edges between them and query those documents. The 'defaultExperience' setting on this db is set to 'graph' and because of this we can toy around in the portal and test queries, so far so good, but when I try to add a azure search indexer it fails because it's not a sql api experience. Could you therefore enable multi api support also UI wise, not just from an API point of view?
James Carter commented
Yes, we need $lookup if we were to migrate, then change our code to directly target DocumentDB SQL afterwards.