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!