Depending on your use-case you have different types of data, that you want to have stored, and with today’s technology, you are lucky to choose from a variety of solutions.
With that variety, you also want to make sure to choose the right option. Since it is as hard as choosing the right pizza, you want to make sure to pick the right one, or else nobody will have a good time with it, especially you.
So let me help you to guide through the AWS menu of different
Before we can dive into the AWS database services, we first need to make sure to know the difference between them. It is as crucial to know what a normal pizza and pizza calzone are. They might sound the same, but they have key features, that make a huge difference and the end.
let’s take a look at what exactly is a relational database and a NoSQL database and their advantages, and also their limitations.
Every relational database follows the ACID characteristics. ACID stands for Atomicity, Consistency, Isolation, and Durability. You can read more about this here. In short: These characteristics are considered a prerequisite for the reliability of systems.
So the advantages of using a relational database are:
Naturally, there are some drawbacks:
When we are talking about NoSQL databases we are typically talking about any database, that is a non-relational database.
In comparison to a relational database, a NoSQL database stores data in a different way. Depending on their data model the data can be stored as a document, key-value, wide-column, or graph.
Since NoSQL databases do not follow strict rules, they provide a much more flexible way to store your data. In general, all NoSQL databases provide the following advantages:
You’ve got also a couple of drawbacks with NoSQL, which you might want to consider:
Most of the drawbacks are already eliminated, when we choose the AWS database service, so you can pick whatever you like.
Now that we know what the difference between a relational and a NoSQL database is, let’s have a look at the different AWS services that you can use, to store your data.
RDS stands for Relational Database Service and as the name suggests it is your pick if you want to have a managed relational database.
In RDS you can choose between a couple of database engines for your needs like MySQL, MariaDB, PostgreSQL, and Oracle, just to name a few. You can find the full list here.
As mentioned RDS is a managed database, you get some additional features with that service:
Now you can see that with RDS, you don’t have any drawbacks that a relational database is giving you with an on-premises solution. Which means, you get all the benefits and no drawbacks. What a great scenario!
For a NoSQL database AWS provides us with DynamoDB. This database provides you with key-value and document data models.
Features you get with DynamoDB are:
And again you can see, that all drawbacks are out of the concern, and you are left with the advantages of a NoSQL database, plus all the features AWS is giving you on top.
It is like eating a great pizza in heaven!
This depends on you and what you want. Do you like Salami, Thuna, or Hawaii (please don’t). Since databases are a crucial part of any application, you better make sure to choose the right fit for your particular use-case.
So instead of just giving you a list of use-cases for DynamoDB or RDS, I’d rather provide you with a couple of questions you need to answer for yourself.
Does your app require ACID properties?
If your answer is yes, stop here and choose RDS.
Although DynamoDB has added DynamoDB Transaction, which provides ACID properties, you also get charged for each request if you use that API.
Do you need high scalability?
If you are trying to create an app, used by millions of people at the same time, NoSQL is the right choice.
If you are building an app, that won’t exceed 100.000 simultaneous client connections, go with RDS.
The same goes for storage: If you do not expect to exceed 16TB of storage for your database, use RDS, otherwise DynamoDB is your choice
Do you already have experience with NoSQL?
Consider your resource if you or somebody on your team already knows NoSQL. If nobody has worked with NoSQL databases before, you need to add additional resources for training to be able to utilize that technology properly and get the full advantage out of it.
Do you expect a lot of changes in your database schemas?
If your answer is yes, DynamoDB is more suited for you.
If not, will go with RDS.
How much will the database cost?
You can check out AWS Pricing Calculator and define a database exactly how you need it to be.
If you answered most or all of the questions in the favor of DynamoDB, use DynamoDB, else use RDS.
RDS and DynamoDB are good initial choices for you, but what if you want to make your life more convenient?
If you want a relational database, but do not want to set up everything yourself, you have AWS Aurora.
Aurora is a fully managed relational database management system (RDMS) and is fully compatible with MySQL and PostgreSQL.
You get all the great features of RDS and on top of that:
With Aurora, it is like ordering a pizza that will automatically give you the right topping, size, cut, and everything else you might need.
You might ask yourself now, why not simply use Aurora over RDS all the time?
It simply depends on your use-case again.
A simple rule can help you with this
Use Amazon RDS if you have small-to-medium intense workloads. If you have an enterprise-level application, go with Aurora. While it has a small increase in costs, the benefits you get with Aurora outweigh this factor.
You can read more about this topic here.
DynamoDB has no service like Aurora (yet), but you can make use of DynamoDB on-demand.
With DynamoDB on-demand you can use the use pay-as-go model and it does not require you to plan your capacity.
This option makes it super easy to get started with DynamoDB. Though it is recommended to switch to a provisioned model, as soon as you know what capacity you need.
Again, you can use the AWS Pricing Calculator to calculate exactly what you need.
When it comes to choosing the right database, you should make a really good analysis of what you need and what you expect. Since a database is one of the most crucial parts of any application, you should consider every aspect, starting from how to implement it, to the costs.
Same as pizza, there is no database better than the other. It all depends on your particular use-case. In some cases, the best option is to use both databases at the same time and take advantage of their strengths.
I’m going to order a pizza now and if you are looking for a solution for your company and need help, just reach out to us.