Best Practices for DynamoDB
Use this section to quickly find recommendations for maximizing performance and minimizing throughput costs.
Table Best Practices
DynamoDB tables are distributed across multiple partitions. For best results, design your tables and applications so that read and write activity is spread evenly across all of the items in your tables, and avoid I/O "hot spots" that can degrade performance.
Item Best Practices
DynamoDB items are limited in size (see Limits in DynamoDB). However, there is no limit on the number of items in a table. Rather than storing large data attribute values in an item, consider one or more of these application design alternatives.
Query and Scan Best Practices
Sudden, unexpected read activity can quickly consume the provisioned read capacity of a table or a global secondary index. In addition, such activity can be inefficient if it is not evenly spread across table partitions.
Local Secondary Index Best Practices
A local secondary index lets you define an alternative sort key for your data. You can query a local secondary index in the same way that you query a table. Before using local secondary indexes, you should be aware of the inherent tradeoffs in terms of provisioned throughput costs, storage costs, and query efficiency.
Global Secondary Index Best Practices
Global Secondary Indexes let you define alternative partition key and sort key attributes for your data. These attributes don't have to be the same as the table's partition key and sort key. You can query a global secondary index in the same way that you query a table. As with local secondary indexes, global secondary indexes also present tradeoffs that you need to consider when designing your applications.