How to Choose a Database on AWS?
Choosing a database is a comparatively long-term commitment for any organisation including startups. Even if you code an app within a distributed system, it captures all changes as a database.
Making an informed decision while choosing a database is as essential as you choose your core team.
In this blog, we walk through the factors you should consider while choosing an AWS database
Let's start with a detailed description of the above diagram :-
The first thing you need to decide is whether you want a relational database or a non-relational database.
If you decide you want to go for a relational database, the next thing comes as ‘do you want managed or unmanaged database?’
If you want an unmanaged database, then you can use the MySQL/Postgres database.
If you want a managed database, then you need to decide whether you have consistent traffic or you have a variable traffic spike like morning is low and at night it is high.
If you have consistent traffic, then I will suggest that you go for AWS Aurora. If you are not sure about the traffic spike, then go for Aurora Serverless.
If you want to go for Non-Relational, then the next question is whether you want to use the database for analytics, business intelligence, and text searching, then go for Elasticsearch DB.
If this is not the case, then do you want transaction workload i.e., multiple updates on multiple tables or multiple changes to this database from several users?
If you want transaction workload, then a new question arises: do you want to scale or want to have an auto-scaling (adding or removing nodes) feature when load increases to balance the load on the database?
If you don’t want scale, then go for DocumentDB even though DocumentDB is a little hands-on and easy to use. Use DynamoDB if you need to scale and it is a serverless key-value database. Here, the scaling is managed by AWS.
Let’s go back to transaction workload. So if you don’t need this then again a question arises: do you need pub/sub message(Publish/subscribe messaging, is a form of asynchronous service-to-service communication) and replication (scale database reads and to have highly available clusters).
If this is the case, then go for Redis. If you want multithreading (the ability to execute multiple processes simultaneously by scaling the computer capacity), then go for Memcached.
Thank you.
I hope this will help…
