[Bellyache5]

I tried Cosmos via the Mongo compatibility layer and performance was abysmal, even when cranking the provisioned performance way up. I ended up getting significantly better performance from a reasonably sized MongoDB container running on AKS.

[tiew9Vii]

Was this taking a MongoDB database app and pointing to CosmosDB or was this developing a app around CosmosDB's partitioning etc but using the MongoDB API for read/write?

The former, lift and shift scenario I can understand as you need to structure your data to work best with CosmosDB/DynamoDB etc. If it's the latter that is useful to know as I'm currently building a POC on Azure so I should watch out for it.

[Bellyache5]

Yes, so not the ideal use case. The compatibility Cosmos offered was nice and didn't present any issues, it's just the performance that suffered.

This was all part of a benchmarking exercise to figure out how to scale an app with minimal changes so we expected some performance penalty, just not as steep as what we observed.

[gqewogpdqa]

I think that makes sense. Using the technology as designed without the “compatibility” layer is likely a better option. Thanks for sharing as many I think wonder about these DocumentDB and CosmosDB MongoDB imitators.

However, CosmosDB is a managed service, easier than setting up your own database. Did you exclude Atlas from your conclusion for some reason? Ie did AKS do things that Atlas could not?

[Bellyache5]

At the time the client wanted to stay inside of the Azure ecosystem so Atlas and the like weren't seriously considered.