Choosing a database that matches your workload and architecture is one of the major decisions you have to make when developing an application. In AWS, this decision may not be straightforward as there are many options to choose from, with each option having its core strength and what it is optimised for. Amazon RDS and Amazon DynamoDB are some of the options to choose from when building with AWS. Both database systems are fully managed by AWS. They are both scalable, easy to set up and operate. However, they work best for different workloads.
Another big difference between RDS and DynamoDB is that they are optimised for different thinking models. In an earlier article, I discussed the DynamoDB Access Patterns’ Mindset and why it is important not to approach DynamoDB with a relational mindset. In the same vein, you shouldn’t approach Amazon RDS like you would approach a NoSQL engine like DynamoDB. While DynamoDB is schemaless, RDS relies heavily on database schemas and relationships between entities. Therefore, you shouldn’t treat it like you would treat DynamoDB because you will run into performance issues if you do.
How do I decide which one to use?
In very simple terms and in practical language, DynamoDB should be used for data that is driven by access patterns. Use DynamoDB if your workload requires low-latency and predictable access patterns. Conversely, RDS should be your choice if your data is structured, relationships between data are important, and there are joins, transactions, and schemas.
RDS is for relational data.
DynamoDB is for access-pattern-driven data.
How are they different?
The big difference between RDS and DynamoDB is in how data is modelled.
In relational thinking, tables and relationships are designed first, and new query patterns can be established subsequently. Relational databases work best for ERPs, Human Resource systems, traditional business applications, and financial systems. If you choose to work with RDS, you have to handle how your connections are managed.
In DynamoDB’s access-pattern thinking, our database is modelled for the queries needed by our application. Therefore, performance and scalability are not issues you need to worry about. This makes DynamoDB ideal for serverless systems, retail carts, high-traffic mobile or web applications, streaming apps, and gaming apps.
When should I choose RDS?
- For complex queries
- For strong ACID (Atomicity, Consistency, Isolation, Durability) guarantees.
- When you need joins and need to establish relationships between data.
- SQL is ideal for reporting and analytics requirements because it syncs well with Business Intelligence tools.
Are you working on a logistics application, bank transactions, human resources or payroll system, or inventory systems? Think RDS.
When should I choose DynamoDB?
- When building a low-latency application that requires fast reads and writes.
- Serverless architecture -
Lambda,SQS, etc. - If your application scales massively.
- For predictable access patterns.
Are you working on leaderboards, real-time booking applications, shopping cart sessions, or an API rate-limiting system? Think DynamoDB.
Can I use both?
The short answer is yes. Some systems use both RDS and DynamoDB. These modern systems use Amazon RDS to carry out analytics and reporting and use DynamoDB for high-volume applications with real-time data.
With this hybrid arrangement, we can both carry out complex reporting and implement fast and low-cost operational workloads.
Therefore, in such an arrangement, RDS is for business analysis and interpretation, while DynamoDB is for write speed.
Wrapping Up!
Whether you choose RDS, DynamoDB or both depends on the system you are working on, the data you have, your technical expertise and how well you understand access patterns and the relationships between data entities.
For structured, relational data that requires flexible queries, use RDS.
For low-latency, highly scalable applications with an established access pattern, use DynamoDB.
As a competent engineer, your choice of database should hinge on suitability with the workload at hand and not on what you are most comfortable with.
Top comments (0)