How can we improve Azure Cosmos DB?

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)

1,565 votes
Vote
Sign in
(thinking…)
Sign in with: oidc
Signed in as (Sign out)
You have left! (?) (thinking…)
AzureEager shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

134 comments

Sign in
(thinking…)
Sign in with: oidc
Signed in as (Sign out)
Submitting...
  • Zachary commented  ·   ·  Flag as inappropriate

    Really? $24/month is too expensive for my church project. I was hoping to use Azure since we don't have the money for our own hardware. I thought the point of the cloud was to support projects at any scale. This is very discouraging.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Currently we r facing lots of RU limit isue with cosmosdb. For a 5 gb of small db i had to make it run as 10.000 RU and this is too expensive. Also monitoring of cosmos is wrong or Cosmos has some bug. Although monitor shows that i am very under the limits, i am getting 429 which is rate limit error. I realy couldn't understand how it is a big data solution. Should i pay tens of 1K USD? By the way we are on Gremlin API

  • Kirill Gavrylyuk commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

    https://scalegrid.io/mongodb.html

  • dahln commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    very expensive compare to azure tables. I used that for everything because Cosmos is way too expensive

  • Jake commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • John commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    We now pay more than $23 per month for a small database that was totally free when using aws dynamo db.

  • Frederik Østerbye commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Please make CosmosDB more cost effective. As others mentioned, the current pricing model is really bad for indie developers and small businesses.

  • Anonymous commented  ·   ·  Flag as inappropriate

    $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.

← Previous 1 3 4 5 6 7

Feedback and Knowledge Base