Azure CosmosDB is too expensive for small but multiple collections
Currently using on-prem MongoDB (on Linux) and wish to move to Azure, but I find CosmosDB is too expensive for small but multiple (MongoDB)collections because it seems that a minimum of 400 RRU's/per second will be charged for each collection.
The terminology used on the pricing web pages is somewhat unclear though and I am not sure if the pricing for the minimum of 400 RRU's/second applies to partitions or collection (or if these terms are in fact identical semantically)
Cosmos DB supports sharing throughput across multiple collections with database-level throughput. This costs approximately $24/month.
Thank you for your feedback on this item. Will be closing this item at this time.
Paul Stanley commented
It's too expenvive as it stands waht a shame. The web page says "Pay for what you use" but its not the case you pay even with no data storage and no read - writes.
It is too expensive to even test out, even at the lowest tier, the bill racks up very quickly. A low tier with a small amount of disk space and other resources would be a huge hit, guaranteed.
Nika Kasradze commented
Almost September 2017. The issue still stands.
My 4 collections each using 400 RRUps cost me $100+ last month. And I was planning on 30+ collections. Guess I'm switching to a custom MongoDB server now, joining the ranks of the mortals :/
Don Wise commented
I was just beginning to develop an app using Azure and I wanted to go with Mongo DB for my database. I made a number of various collections as I began development. Since this is a tinker project, I came back to it a few days later finding it capped my bill to the limit. You can imagine the hair pulling that ensued once you realize the empty collections you created for a tinker project just cost you big money.
This is extremely impractical and if these are going to be so **** expensive, the pricing needs to be more upfront.
sami jan commented
the pricing model should be simpler to understand - and not dependent on the number of collections - otherwise it's prohibitive
We were very surprised to see the cost rack up quickly for even a test instance, and after some digging figured out it was due to the fact that we have multiple (MongoDB) collections, which are charged individually, even if they contain small amounts of data. This rendered the service unusable for us, so we run our own MongoDB service now. I would love to use CosmosDB instead, but it's far too cost prohibitive as it stands today.
all true, pleas fix this limitation!
Daniel Kay commented
The cost per collection model is extremely limiting, and the current pricing calculator is misleading in that you no longer specify an amount of collections which initially made me think that you paid for just storage and RU's regardless of collection count.
Also the minimum of 4x100 RU's makes it very prohibitive to get started.
Tom Tucker commented
I have been arguing this point for years. In Mongo World you pay per Database. A pay per collection pricing is too costly in Mongo. Both DocubmentDB and MongoDB offerings need a smaller unit than the Collection to separate data that does not cost more to organize your data.
For hosting a larger number of very small collections with less RUs under one pricimg tier.
At the moment you habe to pay about 22€ each collection per month, if you habe an application with 30 collection, this is a lot of money.
Alternativly support very small tiers, like 0,5 GB and 50RUs
For backup you can use "Cloudbacko Pro" software as Cloudbacko Pro can Support continuous backup of database and individual mailboxes
Jose Duran commented
DocumentDB price is prohibitive for mobile applications with a database and several collections.
This makes it very expensive to use more than one collection for app.
The solution to this is to have only one database and a collection where all documents are stored, but this does not happen if we use mongo db, where the price per GB is hired, no matter the number of databases or collections.