top of page

Relational vs. Nonrelational Databases

Advantages of Using Amazon DynamoDB for Performance at Scale

Delivering a highly personalized, frictionless digital experience for customers requires a specialized infrastructure to handle the velocity and complexity of your transactional data. How you structure and store that data has a huge impact on the efficiency and reliability of your application.

First, let’s consider the advantages and disadvantages of two primary types of databases — relational and nonrelational — and the use cases for each.

Relational Databases

Relational databases normalize data to save on space by allowing for relationships between data.


Ideal for when your application or data model includes disparate data that is spread out and makes heavy use of join or other referential links in a traditional relational database management system (RDBMS).


Internet-scale applications with high traffic demands often overtax traditional relational databases, resulting in:

  • Increased latency

  • Poor performance

  • Limited capacity

Use Cases

With shopping cart services, details of a product are generally stored only once but referenced from many customers' carts. While product attributes are essential for product detail pages for presentation to the customer, they are not valuable for duplication with every cart that contains that particular item. This is an excellent example of where a relational data model is the right choice.

​Inventory management services (e.g., a warehouse) is another use case where work is based around a subset of highly relational data. This data could include product storage locations and product attributes such as expiration, perishability, size and weight. This data may be important for some functions, but irrelevant for others such as order fulfillment. This lends itself to a relational model that allows access only to the data needed for a given function.

Nonrelational Databases

NoSQL nonrelational databases like Amazon DynamoDB use alternate data management models such as key-value pairs or document storage.


A nonrelational database like Amazon DynamoDB is a great fit for when you don’t know all of the attributes of the data, but you have a fairly clear idea of how the data access will happen. It also provides optimized performance and high scalability for data that can be denormalized (e.g., all of the data elements exist in a single record) — reinforcing the undeniable advantage and value proposition of the cloud:

  • High availability

  • Speed

  • Scalability

  • Efficient use of compute resources (you only pay for what you use)


If you have to report on data with a lot of aggregate or grouping operations, DynamoDB is most likely not a good fit unless it is supported with adjacent services such as Amazon Kinesis Data Streams for DynamoDB.

​Amazon DynamoDB operations for performing aggregate or filters on non-index fields can also be costly and may cause performance challenges if you haven’t carefully considered reporting in the initial design of your DynamoDB tables.

Use Cases

​With user profile data, you may start out only capturing a user's first name and last name, but then later decide you want to request shipping address information.

Amazon DynamoDB allows you to easily extend this data model to accommodate additional attributes and increase what you're storing in the profile in a straightforward manner. In this example, the majority of the data access will be retrieving profile data, and occasionally someone will want to update their profile with new data. This allows you to model your Amazon DynamoDB data and read and write capacity units (RCU and WCU) appropriately from the outset.

Choosing The Right Database For Your Application

We use Amazon DynamoDB as part of a larger microservices strategy to provide companies with flexible, resilient architecture capable of scaling to meet market demand. While you can model virtually any data to be stored in Amazon DynamoDB, there are important factors to consider when evaluating which service is appropriate for your application.

Before making any recommendations, we work with clients to understand their application’s access patterns, reporting requirements, and performance needs. We also consider where data needs to flow to support other parts of your business. This includes Business Intelligence, which might require DynamoDB features such as Streaming data or DynamoDB Accelerator (DAX).

Additionally, any data storage design must be based on your resiliency and recovery needs. By defining your Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO), our architects can design a solution that protects your business in the event of an unexpected failure or outage. All of these factors contribute to a successful design and should guide your database decision.

Whether you’re migrating legacy applications or developing a new app, we can help you evaluate if Amazon DynamoDB is the right choice for your data needs.

Reach out and let us know how we can help.


bottom of page