undefined | Better HN

0 pointsBellyache54y ago0 comments

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.

0 comments

4 comments · 2 top-level

tiew9Vii4y ago· 1 in thread

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.

Bellyache5OP4y ago

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.

gqewogpdqa4y ago· 1 in thread

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?

Bellyache5OP4y ago

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

j / k navigate · click thread line to collapse