Which Azure Database Should I Use for My Serverless Application?

Serverless architectures offer many benefits, including not having to manage and maintain servers, the ability to move quickly and rapidly create prototypes, automatic scaling to meet demand, and a pricing model where you pay only for what you use.

But serverless doesn’t dictate what sort of database you should choose. So in this post, I want to consider the database offerings available in Azure, and how well (or not) they might fit into a serverless architecture.

Azure offers us SQL Database (which is essentially SQL Server in the cloud), CosmosDb (which is their NoSql offering), and Table Storage, which is a very simplistic key value data store. And in fact, Azure is also now offering managed PostgreSQL and MySql databases as well, but I’ll mostly focus on the first three choices.

No More Server Management

The first thing to point out, is that all of these are “serverless” databases in the sense that you are not maintaining the servers yourself. You have no access to the VMs they run on, and you don’t need to install the OS or database. You don’t need to manage disks to make sure they don’t run out of space. All of that low-level stuff is hidden for you and these databases are effectively Platform as a Service offerings.

Automatic Scaling

Another classic serverless benefit – automatic scaling, also effectively comes baked into these offerings. Yes, you may have to pay more for higher numbers of “DTUs” (for SQL Database) or “RUs” (for CosmosDb), but I don’t need to worry about how this is achieved under the hood. Whether Azure is using one super powerful server or many smaller servers operating in a cluster is completely transparent to the end user.

Consumption Based Pricing

One serverless selling point that most of these databases don’t offer, is consumption based pricing. Both SQL Database and CosmosDb expect you to reserve a certain amount of “units” of processing power which you pay for whether or not you use them. SQL Database starts at a very reasonable £4 a month for the smallest database with 5 DTUs and 2GB. Whereas Cosmos Db requires us to spend at least £17 a month for the minimum of 400 RUs. So although we’re not talking huge amounts, it is something you’d need to factor in, especially if you wanted to make use of many databases for different staging and testing environments.

The exception to this rule is Azure Table Storage. Table Storage charges us for how much data we store (around £0.05 per GB) and how many transactions (£0.0003 per 10,000 transactions). So for an experimental prototype where we have a few thousand rows and a few thousand transactions per month, we are talking a very small amount. Of course, the down-side of table storage is that it is extremely primitive – don’t expect any powerful searching capabilities.

Rapid Prototyping

Another reason why serverless is popular is that it promotes rapid prototyping. With the aid of a Functions as a Service offering like Azure Functions, you can get something up and running very quickly. This means that schemaless databases have the upper hand over traditional relational databases, as they give you the flexibility and freedom to rapidly evolve the schema of your data without the need to run “migrations”.

So CosmosDb and Table Storage might be a more natural fit than SQL when prototyping with serverless. It is also easier to integrate them with Azure Functions, as there are built-in bindings, (although I suspect SQL Database bindings aren’t too far behind).

Direct Client Access

Finally, many serverless advocates talk about allowing the client application to talk directly to the database. This is quite scary from a security perspective – we’d want to be very sure that the security model is tightly locked down so a user can only see and modify data that they own.

Ideally, in a serverless architecture the database should also be able to send push notifications directly to the client, alerting them to new rows in tables or modifications of data from other users. I believe this is something that Google Firebase can offer.

However, as far as I’m aware, none of these Azure database offerings are particularly designed to be used in this way. So for now, you’d probably use something like Azure Functions as the gateway to the data, instead of letting your clients directly reach into the database.

Which Should I Use?

So we haven’t really got much closer to deciding which of the Azure database offerings you should use in a serverless application. And that’s because, as so often in software development, the answer is “it depends”. It depends on what your priorities are – do you need powerful querying, do you need to easily evolve your schema, is cost the all-important consideration, do you need advanced features like encryption at rest, or point-in-time restore?

Here’s a simple table I put together for a serverless app I was working recently, to help me decide between three database options. As you can see, there was no obvious winner. I opted to start with Table Storage, with a plan to migrate to one of the others if the project proved to be a success and needed more powerful querying capabilities.

Let me know in the comments what database you’re using for your serverless applications, and whether it was a good choice.