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.
159 comments
-
Russell de Pina
commented
Where Microsoft screws you over is when you're creating collections. It sets the default at 20000 RUs and shows you that it's costing you 38.40 per day, but subconsciously you're thinking per month. Next thing you know you're looking at a $14,000 expense for CosmosDB
NOT COOL AT ALL!!!!
-
Tom Tucker
commented
The problem boils down to the extra cost in separating data without needing extra RU's
At $0.008 / 100RU and 400RU minimum it is not too bad a price at $24.00/mo
Now I need the same RU/s but want to separate a dev collection from a production collection $48.00/mo (unless you delete and recreate the dev collection every time you need it)
What if I want to separate my data by customer each customer in a separate collection 10 customers x $24.00/mo is $240/mo
Ok so now lets move to RU/s per database the new feature that will save us money. It has a 50,000 RU minimum costing $2,880/mo. Thats saving me loads of money.
I do hear they are listening and are working out a pricing model for separating data with low RU at a affordable price. We shall see
-
mleneveut
commented
Apparently, they just changed their pricing model. We now pay for the total Gb of data in the databases, and for the request units per second.
Great news ! (until it changes again...)
-
David Betz
commented
This is extremely expensive compared to Azure Table Storage (which is the baseline price for comparison -- we can't use our finances as a comparison since we all have different financial situations). This is entirely unusable for individual use. I generally rethink my document-models and caress into tabular storage; ATS is affordable.
-
lacmta reg
commented
I talked to an MS engineer that created Cosmos DB about the cost problem and the response I have received was he had no idea what I was talking about since he is not paying anything for it.
-
Rune
commented
Please change the database shared RUs minimum level for MongoAPI from 50000 to around 1000 or even 5000 as a start, in order to allow customers to use this database platform to applications with multi collections but not so high performance needs.
I cannot see why MS have to have this high level, it will only cut off customers to other providers.
This will definitely limit the "Migrate applications to cloud" approach for MS as a choice, unfortunately... -
Jojo Diawuo-Appiah commented
The way i see cosmos db being less expensive is by separating the table in your database that needs the most transaction read/writes and trigger processing and outsource just that table to a cosmos db collection. Ideal for online ledger /transaction tables.
-
It is safe to say that Cosmos DB is for single table stores that need a lot of read/writes and processing and not to be designed like traditional databases?
-
Tom Tucker
commented
Jarle: Most people want to separate their data and are used to tables or mongo collections. What they don't get is there is not the same concept in CosmosDB. The Collection is the whole database. All separation must be handled by your program logic. While I have accepted this I do wish there were Sub-Collections to separate my data at an API level not the query/business logic level.
-
Jarle Nygård commented
The minimum price as of today is about USD 23 pr month, hourly billing. That's not excessive if you ask me...
-
Manuel
commented
The current pricing model implements a pay for not using model. The collections should share the RUs assigned. The current pricing model doesn't fit with the needs of many software (not critical) development projects.
-
Daniel Droke
commented
It would be nice if we had the option of specifying max performance (and potentially storage) for the database or resource set rather than the individual collection, similar to how Elastic Database pools work. This way we aren't penalized for low usage collections, but would never be able to exceed the performance tier we are paying for.
-
Thomas Cooper
commented
The execs should give away say 10gb & 500RUs per class for free across the board whilst they sort it out. Clearly this has been ongoing for 9 months judging by the comments.
-
Thomas Cooper
commented
This is crackers. I've just blown through £120 in 2 days for a DB that sat on an MLAB sandbox & would be more than happy on one of their $15/month shared plans.
I've asked Azure for a refund as their pricing model is completely opaque for this service.
-
Tom Tucker
commented
I think most people can't wrap their head around the pricing model of pay per collection. People want to separate their data without added costs. When is a Sub Collections feature coming?
-
Isaac Abraham
commented
Chris - to be fair DynamoDB and Cosmos are both very different services with different feature sets. Probably Azure Table Storage is a closer match to Dynamo than Cosmos, with a similar pricing model. Whilst I agree that Cosmos is very expensive compared to Dynamo, it's most likely not a good fit for your needs as if you're happily using Dynamo now, you might not need the extra features of Cosmos.
-
Chris
commented
Yep, just hit the exact scenario everyone here has experienced... Astonishing... I was comparing Azure Functions and CosmosDB to AWS Lambda and DynamoDB and THERE'S NO WAY I'm leaving AWS for Azure... Guess MS is now the IBM of the industry and only caters to corporate shops that literally throw money away.... Perhaps if Cosmos was substantially better than Dynamo, then *maybe* it would be worth it. But, honestly anyone else reading this and trying to consider AWS vs Azure, don't even waste your time. The industry has adopted a "pay for what you use" model, that's the standard model for cloud now and apparently MS doesn't care... Like everyone else on this thread, I had little or no data in my collections during my POC testing and ran only a handful (less than 50 requests TOTAL) during my dev/test process and I was billed over $150 for the past two weeks. So, I'm closing this free trial and never looking back.
And to another commenter's point about their "pay for what you use" advertising, that's in fact fraudulent.... Simple untrue. Of course, their legal team would say "you're RESERVING AND THEREBY USING our resources". And yet, I personally am not storing ANY data or making ANY requests and still being charged... I mean, MS... Stick to your fat corporate customers that are locked into SharePoint and .Net and gouge them for millions / year b/c they're simply too lazy, too stupid or can't overcome the inertia of having a large SP portal or .Net app that they THINK they can't run anywhere else... But, look you can run .Net Core AWS Lambda apps so even most of those criteria for locking in legacy customers are going to be eliminated soon. Ah well, gave it a test run but no thanks, sadly so...
There's simply no way around the model of hosting some services on AWS and the rest on our own hardware if you're building a new app / startup. That continues to be the best possible deployment and I was hoping at least another major cloud provider would compete with AWS... But, MS is catering strictly to their corporate accounts.... FYI in case you're considering deploying a new app...
-
Tom Tucker
commented
I have come to the conclusion that CosmosDB is catering to the very large datasets that want fast query times. The smaller projects that don't need the scale are not important to them. They forget that once you go to a Document Database you never want to use SQL server tables and rows with schema again. There is a large audience for small hosted document databases that CosmosDB is not catering to.
The standard response to save money is to put everything into one Collection. So I do something like this so I can query document types and different company's all in the same collection
using Microsoft.Azure.Documents;
public class TDocument : Resource
{
[JsonProperty("_type")]
public string _type => this.GetType().Name;
public string _companyId => ...
} -
Dave Childs
commented
Agreed. I was shocked at the hit my MSDN credits took for two very simple dev/test databases.
-
Long Le commented
Same issue here...