0 Comments

Azure offers a number of “databases” as a service. There’s SQL Azure, which is a great choice when you want a relational database that you can use with Entity Framework or query with your own custom SQL.

There’s also Azure DocumentDb which is Microsoft’s “NoSQL” offering – giving you the benefits of a schemaless document database approach, while retaining powerful querying capabilities. If you’re familiar with using NoSql databases like MongoDb then it’s an ideal choice.

And then there’s Azure Table Storage, which Microsoft describes as a “NoSQL key/attribute store”. This means that it’s got a schemaless design, and each table has rows that are made up of key value pairs. Because it’s schemaless, each row doesn’t have to contain the same keys.

But compared to DocumentDb, Table Storage is very rudimentary. There are only two indexed columns on our tables – RowKey and PartitionKey, which together uniquely identify each row. So it’s not great if you need to perform complex queries. In DocumentDb, each “document” is a JSON object that can have an arbitrarily deep structure. But in Table Storage, you’d need to manage serialization to JSON (or XML) yourself if you wanted to store complex objects or arrays inside columns.

So, compared to the more powerful capabilities of DocumentDb, Table Storage might seem a bit pointless. Does it have any advantages?

Well the main big advantage is cost. Even for the cheapest DocumentDb database, you are looking at $23 a month for a single “collection” plus a small amount more for the total data stored. This may be reasonable for production apps, but for small experiments or prototypes, it can add up quite quickly and probably force you to try to store the documents for multiple apps in the same DocumentDb collection which could get messy.

With Table Storage, you don’t pay a monthly fee, but instead pay very small amounts for the amount of data stored and the number of transactions you use. This means that for prototypes and proof of concepts it works out insanely cheap. It’s currently the only database choice in Azure that follows the “serverless” pricing model of paying only for what you actually use.

This means that Table Storage can be a good choice as a “poor man’s” NoSql database. I’ve been using it on a number of projects where I just need a couple of simple tables, and where my querying requirements are not complex. Another advantage is that it integrates very nicely with Azure Functions, making it a great choice if you want to quickly build out a “serverless” prototype.

Of course, Table Storage is also designed to be able to store huge volumes of data. So another use case it’s great for is for storing logs and diagnostic information. In fact, a several Azure services (like Azure Functions for example) use Table Storage as the backing store for their own logs.

So although Table Storage may not be the most exciting or flexible database option, if you know what it’s strengths are, it can be a useful tool to have at your disposal. There’s a helpful tutorial available if you want to get started with Table Storage using C#.

Want to learn more about how easy it is to get up and running with Azure Functions? Be sure to check out my Pluralsight course Azure Functions Fundamentals.
Vote on HN
comments powered by Disqus