4

Since DocumentDB and MongoDB are both document-oriented DBs it seems that they can model the same type of data and both are well suited for to solve the same problems.

Besides the different ecosystem, DocumentDB's lock-in to Azure, and strengths/experience of the team, is there anything else to consider when choosing one over the other?

I would assume that since DocumentDB was developed by Microsoft for Azure, with CosmosDB architecture in mind, it would have a cost advantage over the MongdoDB API? How big of a cost advantage is DocumentDB-API over MongoDB-API for the same type of data storage & requests?

I'm trying to decide between CosmosDB DocumentDB-API and CosmosDB MongoDB-API for a new project. Thanks.

If you were to start a new project on CosmosDB, and know DocumentDB and MongoDB equally well, and needed a document-oriented db, which API would you choose and why?

Stennie
  • 63,885
  • 14
  • 149
  • 175
Quang Van
  • 11,475
  • 12
  • 57
  • 61

3 Answers3

2

You should choose the API that makes the most sense for your particular scenario - which includes a large # of factors to consider e.g. is this is a greenfield project vs existing project, what do your particular data access patterns look like, do you use standard JSON data types versus MongoDB-specific data types, etc.

The long-term goal is to achieve parity in terms of robustness between all of Cosmos DB API's. With that said, the DocumentDB API is the most battle-tested as it has been around for a longer period of time.

Andrew Liu
  • 8,045
  • 38
  • 47
  • It's a greenfield project. What do you mean by "data access patterns"? Pretend I don't know MongoDB, so I can use either MongoDB-API or DocumentDB-API. How do I decide? Are there anything major that I should look at? – Quang Van May 17 '17 at 20:55
2

I would only use the MongoDB API if you have requirements to access the database directly on unsupported platforms (like PHP). When using the DocumentDB API, you need to use the REST API. There is a MongoDB API for PHP, so this would be much more convenient.

The DocumentDB API is made for CosmosDB, so it will have the broadest feature set.

Keep in mind that CosmosDB doens't provide all the MongoDB features. The aggregation framework is missing, so you don't have $groupby, distinct, ... to your disposal. Despite MS saying that CosmosDB can be used as a managed MongoDB solution you should careful check what you need before switching to CosmosDB.

Ramon de Klein
  • 5,172
  • 2
  • 41
  • 64
2

There are lots of things to consider but one I haven't seen mentioned yet is that DocumentDb doesn't support update operations that don't replace the entire document. Whereas MongoDb has the $set, $unset, $push, $pull and some other operators that allow you to modify a portion of the document.

schmidlop
  • 1,356
  • 16
  • 31
  • Do you have an example of how to use the MongoDB features like $push? – tzwickl Aug 31 '18 at 12:46
  • CosmosDB does have the Patch API now - it is still true though that Mongo API provides a lot of useful primitive operations that you would need custom coding for with the No SQL API. I use both. For me the most irritating thing about Mongo API is that it often lags far behind feature parity with the No SQL API. e.g. It is still not possible to switch existing Mongo API collections over to analytical store but this has been possible with No SQL API for ages and there is still no Azure function support using Mongo API change streams implementation – Martin Smith May 29 '23 at 11:06