Amazon constantly proves, that in terms of scalability, DynamoDB has practically no limits. It can easily handle hundreds of milions of requests per second with a single-digit miliseconds latency. However, that power is not free. DynamoDB achieves its incredible ability to scale thanks to strict limitations - these limits, both in usage and in query patterns, can be pervieced as guidelines on how to use NoSQL database in a proper way.
What are these limits? Let's start with the most important one:
Item size limit
DynamoDB's limit on the size of each record is 400KB. You might think it's very inconvinient but it's for your good - this limit makes it less likely that you will make a mistake when designing your database.
If you have a lot of data, you should consider denormalizing it, breaking it into multiple items, or store it in a different place. For example, if you want to store an image, upload it to Amazon S3 and instead of putting them in DynamoDB, save just a link to it.
If you have a lot of related records, you might store them all in a single record in DynamoDB as a big nested JSON. However, as number of informations contained in this blob increases, your application performance will degrade too. You'll likely end up fetching alot of unnecessary data and eventually even break the 400 KB limit. This limitation forces you to consider access patterns upfront and think about denormalization.
DynamoDB Indexes allow you to create additional access patterns. GSIs (Global Secondary Index), aka indexes that use a different attribute as partition key, are limited to 20 per table. However, that limit can be increased by asking the support. On the other hand, LSIs (Local Secondary Index) are hard-capped to 5 indexes. That isn't a big deal. Usage of LSIs adds yet another, often overlooked limitation - it imposes a 10 GB size limit per partition key value. For that reason, you should probably always favor GSIs over LSIs.
Scan and Query operations
DynamoDB Scan and Query are two main operations to fetch a collection of items. These two operations have not only similar syntax - both of them can also return up to 1 MB of data per request. If the data you're looking for is not present in the first request's response, you'll have to paginate through the results - call the operation once again but with
NextPageToken set to
LastEvaluatedKey from the previous one.
Transactions and Batch Operations
Transactional and Batch APIs allow you to read or write multiple DynamoDB items across multiple tables at once.
TransactWriteItemsis limited to 25 items per request
TransactReadItemsis limited to 25 items per request
For batch operations:
BatchWriteItemis limited to 25 items per request
BatchGetItemis limited to 100 items per request
Partition Throughput Limits
DynamoDB Tables are internally divided into partitions. Each partition has its own throughput limit, it is set to 3,000 RCUs (Read Capacity Units) and 1,000 WCUs (Write Capacity Units). Because of that limitation, it is extremely important to design your application to distribute reads and writes evenly across all partitions, or in other words, across all logical partition keys.
Unfortunately, it is not always possible to distribute that load evenly. In cases like that, "hot" partitions (the ones that receive most of the requests), will use adaptive capacity for a limited period of time to continue operation without disruptions or throttling. This mechanism works automatically and is completely transparent to the application.
- Throughput Default Quotas per table - 40,000 read capacity units and 40,000 write capacity units
- Partition Key Length - from 1 byte to 2048 bytes
- Sort Key Length - from 1 byte to 1024 bytes
- Table Name Length - from 3 characters to 255
- Item's Attribute Names - from 1 character to 64KB long
- Item's Attribute Depth - up to 32 levels deep
- ConditionExpression, ProjectionExpression, UpdateExpression & FilterExpression length - up to 4KB
DescribeLimitsAPI operation should be called no more than once a minute.
There's also a bunch of reserved keywords.
© 2022 Dynobase