How to choose a database in AWS

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 pizza databases.

NoSQL VS relational

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.

Relational databases

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:

• Simple Model: In comparison with other database models, it has the most simple model.
• Security: An admin can give access to specific tables for each user.
• Easy to use: Easily retrievable data with SQL Queries.
• Accuracy: No duplicate data.
• Data Integrity: Makes sure that the data is accurate, complete, and reliable.
• Collaboration: Multiple users can access the database at the same time.

Naturally, there are some drawbacks:

• Maintenance: It becomes difficult over time to maintain a large amount of data.
• Cost: It is costly to set up and maintain, at least on-premises.
• Lack of Scaleability: Scaling up a database on your own requires a lot of resources
• Decrease in performance: With large data, queries might take some time

NoSQL

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:

• Flexible: Easy to adapt the database to new data
• Horizontal scaling: easy to add additional nodes
• Easy to use: Especially from a developer perspective

You’ve got also a couple of drawbacks with NoSQL, which you might want to consider:

• Lack of Standardization: The query language varies a lot from different NoSQL databases
• Less flexible queries: Especially with complex queries
• Data inconsistency: That is the nature of the distributed approach

Most of the drawbacks are already eliminated, when we choose the AWS database service, so you can pick whatever you like.

Let’s move to the cloud

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

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:

• Security and Compliance
• Perfomance and scalibility
• Automated patching and upgrades
• Data durability and redundancy
• Monitoring and alerting
• Backup and recovery

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!

DynamoDB

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:

• Backup and restore
• encryption at rest
• NoSQL workbench
• point in time recovery
• on-demand capacity mode
• and others

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!

What do you pick?

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.

Do you need to follow some compliance with your data?
Check out both services if they meet your needs:
DynamoDB compliance
RDS compliance

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.

Something extra

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:

• High Performance and Scalability
• High Availability and Durability
• Highly Secure
• Fully Managed
• Migration Support
• Cost-effectiveness
• Developer Productivity

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.

What about DynamoDB?

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.

Conclusion

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.