Allow Database Level Pricing
I am looking to convert an application from MongoDB to DocumentDB as I would prefer a managed solution but the collection pricing is absurd. The current model has 1 or 2 collections with 10+ GB of data that will grow at high rates but there are another 30 collections or more with most of them having only 10-20 records. Paying a minimum of $25 per collection is out of the question especially for dev workloads. The pricing model would change your development behaviour to just stuff everything in the same collection but then you loose a lot of the ability to index and know what you are looking at. Until the pricing gets fixed the product is a bad replacement for MongoDB.
Database level pricing is now generally available. Learn more about it here, https://docs.microsoft.com/en-us/azure/cosmos-db/request-units
Simon Luckenuik commented
"Throughput provisioned at the database level now starts at 400 RU/s per database and can be shared across any or all containers within a database."
Dan Gander commented
taking https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/17893705-allow-database-level-pricing into account, this is now at 2062 votes - the 3rd most requested thing on Cosmos...
We are so close to having this fixed. MS has built it (database level throughput allocation). They've just priced it so that no one can use it (as of this comment the minimum allowable RUs is 10k which the portal says costs about $20 a day). I've brought this up to CosmosDB and they're still a bit confused about the issue. I still get the official line of 'collections are schema-agnostic so put all your documents in a single collection'. The issue with this, and it's been the issue since day 1 is that collections are NOT schema agnostic. They're the unit of indexing and the unity of partitioning, neither of which is schema agnostic. One collection per document type is the only thing that makes sense for me.
Derek Gabriel commented
Need to take into account the 960 votes on (
https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/19466308-azure-cosmosdb-is-too-expensive-for-small-but-mult) as it's a duplicate... with over 1800 votes together that puts this in the top 5... I think the community is speaking loud and clear.
Hello? Anyone there who is looking to this post? Hello? Nothing...
I've run into the same problem after migrating from Azure Table Storage, I used one collection per entity, but that was too expensive, so I wrote an article on how I solved it by creating a repository that handles the separation of entities while storing them all in one collection. This way, I could keep my business logic intact and just change the data layer, check it out here: https://tareksharbak.com/multiple-entities-in-one-collection-azure-cosmos-db/
Why not merge this with 'Azure CosmosDB is too expensive for small but multiple collections' it is the same issue really. Would make this 4th most requested feedback
Cody Schnacker commented
We are also experiencing pain with this.
I really don't understand why this decision was made in the first place. It seems obvious that the minimum RU/s should be set on the database, not per-collection level. It is a bit concerning why this decision was not made.
Rick Stephens commented
I'd like to add my $0.02. Charging by the collection is going to encourage developers to take up bad practices and try to store many different document types inside of single collection in order to save money. This is akin to having a one database table to rule them all inside of SQL Server database. Just. Because. You. Can. Do. It. Does. Not. Mean. You. Should.
I agree there needs to be a free version of Cosmos DB for dev and trial users. There is however one thing that some people don't realise after looking through the comments:- You don't need a separate collection for each entity, you can split entities by just having an EntityType field.
Jonathan Little commented
We need some way to pool across some much lower baseline that isn't 50,000RUs, especially for test environment loads. Azure is missing a happy-medium solution between slow, dirt cheap table storage that we can't really query and this Rolls Royce of a database that essentially costs hundreds of dollars per month to enter for any realistic use case of it with a non-monolithic architecture.
I can't have my apps live in Azure if I can't keep the data next to them, so the high cost of Cosmos DB is affecting sales of other Azure PaaS products as well.
Nathan Becker commented
Wanted to chime in here about the necessity of having a much-lower-priced tier - we have developers with MSDN Azure accounts that want to use CosmosDB in testing environments (super low RU count, multiple collections), but will quickly run out of the provisioned Azure credits if they run it full-time alongside the other resources they need to allocate. The best workaround I've been able to come up with is to run the data migration tool every weekday night to back up the documents to an Azure storage account, delete the collections, and then in the morning, create the collections and restore the data, thus bringing down the cost to ~$6/month per collection, but that is quite a janky, high-maintenance workaround that is not sustainable long-term. If there was a pure consumption-based pricing tier, or the ability to pool collections with the 400 RU baseline, or even the ability to stop the database so as not to incur resource costs, that would be ideal for us.
Dan Friedman commented
I think this can be marked as completed. See https://azure.microsoft.com/en-us/pricing/details/cosmos-db/
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...
Eric Barch commented
I certainly agree with the other devs. We've been looking forward to moving to Cosmos DB due to the technical benefits.
But after seeing the pricing, we're now looking outside of the Azure ecosystem for our DBs. A single microservice that has several collections (but very little data) should not cost upwards of $3000/mo to provision a DB.
Hahaha, 50K minimum. I guess that's one way to say you're listening to customer feedback. Why is Microsoft even advertising this database to the average developer? Clearly they don't care about that market.
JJ Kennedy commented
So per database pricing is available but the minimum RU is 50K. So minimum $4,200 a month. This is just ridiculous!!!
I was looking at the docs to switch from self-hosted mongodb server to cosmos db when I read that the pricing is per collection. This is absolutely insane.
Announced at build is database shared RUs...
I hope you have a **** ton of containers to make it worth while. Provisioning starts at 50K RUs
Lei Sun commented
I give up on this. Look good. But, the price model is ridicules. I have a lot of collections. I need to pay for each.......................................................................