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)
AzureEager
shared this idea
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.
Thank you.
152 comments
-
Kirill Gavrylyuk
commented
Dahln, when provisioning throughput at the database level, if you have 20 containers, you can provision as low as 2000 RU/s (100 RU/s per container). The entire throughput is shared among all containers. This would cost you ~$3.84/day or less. The equivalent Atlas config is M20, which is $5.76/day. Happy to work further through this on email.
-
Kristi Vilione
commented
Check out ScaleGrid's MongoDB hosting plans. They are the only multi-cloud DBaaS that lets you host in your own Azure account through their BYOC plans. This means you're able to use reserved instances to lower your long-term hosting costs vs. paying the high on-demand pricing through Atlas, and leverage VNET and security groups.
-
dahln
commented
My company just launched a new product, and we really wanted to use Cosmos DB to host MongoDB. Our database has about 20 collections. By our estimation, we would spend $20-$30 a day to host our database. This is simply unacceptable. Instead we are using Atlas - the pricing is simple and affordable (about $60 a month). I would be willing to switch when CosmosDB has a comparable price - my suggestion is that Cosmos DB should not charge by RU, but rather size and throughput (with 1tb of transfer allowed without extra cost).
-
Will Lee
commented
very expensive compare to azure tables. I used that for everything because Cosmos is way too expensive
-
Zach
commented
Never imagined we'd pay so much for small collections.
-
Jake
commented
WHY, why is Cosmos DB so expensive? I migrated my schema (15 collections so far) with 100 RUs each (smallest possible, I believe) and I have very few data in these collections yet I'm being billed extra. Why is creating a simple collection that is NOT being utilized so expensive? What happened to "pay for what you use"? We still need the team to improve in this area.
-
Anonymous
commented
So my first full Cosmos bill has arrived ... Sorry MS, paying £65 a month for a TINY dev/test database is ridiculous. In fact it's so ridiclous I'm not going to carry on using it.
-
Yohan S.
commented
Using the shared pricing model is really helpfull but all collections in a dev/test environments will also have small number documents stored.
In the Bizpark subscription, we have 130€ available / month and it's currently limiting the usage to 22 collections with the current 100RU limitation / collection.
Until we get a serverless pricing model,
Can you lower (once more) the entry price / collection please?
(something like 10RU/collection would help our dev/test env to be setup correctly. And we will have 1000 or 1500 RU shared trough all the collections) -
Stefan Reichel
commented
The new database-shared trhoughput definitely hepls. Although the bill can still get quite high because of spiky workloads. We have a data source that sends large amounts of data in irregular intervals while in beteween there is not that much going on. We still have to keep the RU slider quite high because of the spikes. A true serverless pricing model would be a real help here because it still costs way more than using MongoDB Atlas. Especially for dev/test environments where one still pays a relatively exorbitant amount of money if you want to keep your environments the same in structure and setup.
-
Daniel
commented
Ugh. I just saw my bill and it looks huge!! I didn't even store anything. Now, I'm being charged because the default collection setting reserves enough RUs to cost you a lot of $$$. This wasn't clear to me. I definitely want Cosmos DB to cost less.
-
Alex
commented
Please offer free tier for very small projects!!
-
John
commented
I totally agree with the original comment. We too were burned with a tiny Cosmos system we were using to prototype before scaling up. We have completely turned it off.
The pricing is very unclear. You can set up a shared database but then have to code to use shards across different collections. The RU/s measure is really confusing. You are given a free 100 RU/s tier when you sign up, but the minimum is 400 RU/s, so the "free" addition is meaningless.
We originally had 8 collections with the intent to grow to about 20. By default it put 1000 RU/s into each one (we didn't understand the complex pricing). The cost per day for 1000 RU/s is $1.92. 20 collections x 30 days x $1.92 = $1,152 per month for a database that was about 100 MB. The equivalent on Atlas MongoDB is zero.
I raised the issue on Microsoft support and the initial answer was that they didn't know about Cosmos.
I cannot understand why anyone would use this. My recommendation is go elsewhere.
-
Alex
commented
We now pay more than $23 per month for a small database that was totally free when using aws dynamo db.
-
Frederik Østerbye
commented
This update seemed so promising, but you totally forgot to mention that you need at least 100 RU/s per collection.
For our scenario we have a DB with 25 collections, but with an average throughput of 0,67 RU/s.
We're paying 193 USD per month for a development database.Come on, MS! This is simply not very cost effective if you need replicated instances to support DEV, UAT and PROD.
-
Jim Brown
commented
The new database level offer is great! But it is very confusing on how to move between "tiers" of RU throughput at the database level. For example, if you provision a database with 20000 RU/s, you can't scale it down to 400. You have to start at 400. And if you go above 10000 you get moved to a higher tier and can't come back down again! We had a process planned for daily imports that scales the database way up just during the import but we got locked in and had to delete the entire database just to scale it back down!
-
Jake
commented
Please make CosmosDB more cost effective. As others mentioned, the current pricing model is really bad for indie developers and small businesses.
-
Anonymous
commented
$5/mo. entry would help get us hobbyists in the door. The new pricing is a start but $23/mo. is still out of reach.
-
Dan Friedman commented
I finally found an article about this: https://azure.microsoft.com/en-us/blog/azure-cosmos-developer-experience-updates-december-2018/#db-level-throughput
So in a shared throughput database, you basically need 100 RUs per collection, with an overall database minimum of 400 RUs.
I'd still like to see this be more "pay as you go", but this is a *huge* improvement.
-
Tom
commented
I just spent some time playing with this update finally... The Azure Portal won't let me set a database throughput of <100 RU/s per collection. I have 6 collections in a database and get an error trying to update my database throughput to 400 RU/s: "The replace operation is invalid, OriginalOffer: 600 RUs, NewOffer: 400 RUs"
Is this part of the design? I couldn't find this mentioned anywhere in the pricing details page. -
josie
commented
You could create a subcollection field within each distinct document set and then you can keep everything in one collection and just query them out using by subcollection.