Comparing DynamoDB to Other Databases
Start course
4h 25m

This section of the AWS Certified Solutions Architect - Professional learning path introduces you to the AWS database services relevant to the SAP-C02 exam. We then understand the service options available and learn how to select and apply AWS database services to meet specific design scenarios relevant to the AWS Certified Solutions Architect - Professional exam. 

Want more? Try a Lab Playground or do a Lab Challenge

Learning Objectives

  • Understand the various database services that can be used when building cloud solutions on AWS
  • Learn how to build databases using Amazon RDS, DynamoDB, Redshift, DocumentDB, Keyspaces, and QLDB
  • Learn how to create ElastiCache and Neptune clusters
  • Understand which AWS database service to choose based on your requirements
  • Discover how to use automation to deploy databases in AWS
  • Learn about data lakes and how to build a data lake in AWS

Let's take a look at how DynamoDB compares to other database technology that you might already be familiar with.  You've probably already worked with a relational database like MySQL, Oracle, or Microsoft SQL Server.

It’s important to understand the differences between DynamoDB and relational databases. 

The first big differentiator is how NoSQL databases scale. Relational databases scale vertically, meaning if you need more power and CPU, you increase the size of your server. You get a bigger box. DynamoDB scales horizontally, meaning if you need more power and CPU, you add more servers into your fleet. You get more boxes. This is how DynamoDB can scale almost infinitely. The true benefit of this is that it scales transparently to the user. With most relational databases, you have to manage the scalability. With DynamoDB, it scales storage for you, and depending on the capacity mode you choose, it can either scale compute for you as well or at least offer Auto Scaling functionality. 

The second factor is in the schema. Relational databases have a fixed schema, while DynamoDB is considered schemaless, so you don't have to define a fixed table structure in advance. When you insert a DynamoDB item, it can have any attributes that it needs - even if other items don’t have the same attributes. The benefit is you can adjust columns and data types on the fly.

However, there are some downsides to using DynamoDB in comparison to relational databases.

For example, if you’re used to SQL and writing advanced queries with joins, groupings, and summaries, DynamoDB's built-in query and scan features aren't as flexible as what you can do with SQL. However, DynamoDB does support PartiQL, which is a SQL-like language for querying and modifying your data. This may make DynamoDB a bit more approachable for some, enabling you to write more complex queries using a SQL-like language that gets converted to DynamoDB queries and scans on the backend. That being said, it’s worth noting that it only supports a subset of the PartiQL language.

DynamoDB also doesn't offer the wide range of data types that many relational databases do. DynamoDB only has a few native data types, such as strings, numbers, Boolean values, binary data, and null values. It also supports lists, maps, and sets. However, if you work with data types like dates, you'll need to represent those as strings or numbers in order to store them in DynamoDB. 

Now if you’re already used to NoSQL databases like MongoDB or Cassandra, then DynamoDB might feel more at home. Still, NoSQL databases vary quite a bit within their own category. For example, MongoDB is a JSON document-based database, while DynamoDB supports key-value and document data models. MongoDB is platform agnostic, while DynamoDB can only run in an AWS environment. You’ll find that the two vary quite a bit. 

The last important thing to understand is that DynamoDB has some strict limitations in the way you're allowed to work with it.  For example, one hard limitation is the maximum item size of 400 kilobytes. If you’re frequently storing large objects per item, you’ll need to instead store those objects in a cheaper storage solution such as Amazon S3, and store the reference in DynamoDB to get around this limitation. It’s also worth noting that there are some softer limitations that can be adjusted by contacting AWS Customer Support, like the maximum number of tables in an AWS account and the maximum throughput limitations. 

That’s all for this one - see you next time!  

About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.