A while ago, Microsoft announced that you now also have the option of running Azure Cosmos DB in a free tier. I am super excited about this! So far, the minimum cost of Cosmos DB has been a bit of a problem in some cases. Especially in small and personal hobby projects. Until now, the minimum cost for Cosmos DB has been roughly 20 EUR / month.
You may argue that the cost is not that big. I can agree with you on that, partly. But if you compare that cost to the cost of other storage options in Azure, it is substantially higher. That’s why I’m so glad to hear that you can now start with Azure Cosmos DB for free! That makes Cosmos DB the most flexible and scalable storage option there is in Azure. There is no upper limit on how big you can scale your Cosmos DB account.
I’ve been a fan of Azure Cosmos DB for quite a while. That’s why I wanted to give the free tier a spin. This article is a summary of what I’ve learned so far.
Pushing the Limits
In Cosmos DB, you can create one database and configure it with shared throughput. This means that all collections in that database will use a shared quota. In the free tier, you can have up to 25 collections in one database. All of these collections will share the 400 RU/s that comes with the free tier.
This means that on average, each collection will only get 16 RU/s. If you have a constant load on all of these collections, you may run into trouble. But, in more occasional scenarios, you can get very far. Basically, you can have 25 different applications with their own collection. All for free.
To push the free tier to the limits, I decided to create a test console application that would constantly, read, write and delete data in Cosmos DB. And do this in parallel in multiple collections. I initially started out with just 10 collections. But with the quite encouraging results I got, I decided to increase the number of collections to 20.
The documents this test application writes is just randomly generated text. Just trying to simulate JSON documents that you typically would store in Cosmos DB. The average size of the documents is a bit less than 2 kB. 1,75 kB to be exact. This means that it would require 1,75 RU/s to read such a document. To write such a document would consume 8,75 RU/s. This is because it takes 5 times more throughput to write content than to read it. In addition to the direct RU charges for reading and writing, there is also a slight overhead for reading and writing the indexes.
What About the Numbers?
I’ve now been running this test application for around 3 days. The statistics for this database with 20 collections in it, is shown in the picture below.
As you can see, I’m over the 400 RU/s limit slightly. That’s been the case throughout my test. Seems that Cosmos DB is giving a little bit more than it promises. However, I have not verified that, and I’m just relying on the stats the Azure portal gives me.
The number of requests I’m getting through is also quite promising. Remember that I’m doing a mix of reading, writing and deleting JSON documents with an average size of 1,75 kb. So an average of 80 such requests every second is quite good I think.
I’m constantly hitting the throughput limit of 400 RU/s. You can see this from the chart below. At least I’m not limited by my network capability at home (enduring the corona quarantine), since I’m able to generate requests enough to get throttled.
This chart shows the hourly average of the requests over the last 7 days. The beginning of the chart is empty, since I just started about 3 days ago.
Using the Cosmos DB SDK
As you can see from the previous chart, a lot of requests end up with an HTTP 429 response. This means that Cosmos DB is rejecting the request due to heavy load. However, that sounds worse than it actually is. I am using the Cosmos DB SDK v3, which handles these throttled requests very gracefully. If Cosmos DB throttles a request, it also returns the number of milliseconds the caller must wait before retrying the request. The SDK takes care of this, so I don’t have to do anything. And as you can see, I’m hitting the limits quite hard. Roughly 25% of all requests end up being throttled.
In fact, I’m hitting the limits so hard, that occasionally, the SDK will throw an exception if it can’t get the request to go through after a few retries. However, they are not that many. And normally, if your application would be hitting the limits and get throttled, you would just need to add some RU/s to your database or collection, and you would not hit those limits any more.
In the last hour of my test, I have been getting over 126 000 throttled requests. Only 80 of those bubbled up as exceptions that my test application had to catch. That is about 0,06% of the throttled requests end up throwing exceptions to the application. During the same period, my test app got around 175 000 requests successfully completed. And that is just during the last hour (at the time of writing).
What About the Cost?
So, is all of this really free? Well, yes, more or less. As long as you don’t exceed 400 RU/s throughput and 5 GB of storage. The throughout is easy to handle, as long as you don’t go with the autopilot, which is in preview for the moment. The storage is a bit trickier, since there is no configuration that you could set to limit the storage size to the 5 GB included in the free tier. You just need to monitor your Cosmos DB account, if you think there is a risk that you might go over the free storage allowance. The free tier is implemented as a discount that is applied to your Cosmos DB account. The discount is estimated at $24 / month, but should be enough to cover 400 RU/s and 5 GB of storage.
From the chart above, you can see that my current daily cost is $0,84/day. For 30 days that would result in a cost of $25,2. I guess the estimated discount of $24 will cover this, since these are just estimates. I’ll just have to wait and see at the end of the month when I get the bill for my subscription.
So, is the free tier in Azure Cosmos DB any good? I would say definitely! The best of all is that you can start from zero, and scale up indefinitely, in case your application would need to increase on the throughput or storage.
I would definitely recommend Cosmos DB for your future applications. Compared to Azure table storage, Cosmos DB supports a lot more complex queries than table storage. And if you compare to relational databases such as Azure SQL Database or Azure Database for MySQL, Cosmos DB is just so much more flexible. Also the cost of Cosmos DB is more linear when the load increases. Relational databases tend to have a more exponential cost in relation to the load on the database.
To learn more about Azure Cosmos DB and the free tier, check out the links below.