Why is the restore of my Amazon DynamoDB table taking a long time?
Last updated: 2022-08-09
I'm trying to restore my Amazon DynamoDB table, but the restore process is taking a long time.
When you restore your DynamoDB table from its backup, the restore process is completed in less than an hour in most cases. However, restore times are directly related to the configuration of your table, such as the size of your table, number of underlying partitions, and other related variables. When you plan disaster discovery, it's a best practice to regularly document average restore completion times and establish how these times affect your overall Recovery Time Objective.
The time DynamoDB takes to restore a table varies based on multiple factors and is not necessarily correlated directly to the size of the table. If your table contains data with significant skew and includes secondary indexes, then the time to restore might increase. When the restore process is in progress, the table status is Restoring. When restore is completed, the table shows the status as Active. All backups in DynamoDB work without consuming any provisioned throughput on the table.
Keep the following in mind when you are restoring a DynamoDB table from its backup:
- The restore times aren't always correlated directly to the size of the table.
- When you perform a point-in-time recovery of a DynamoDB table, the restore process takes at least 20 minutes irrespective of the size of the table. This is because after you restore, DynamoDB needs time to provision all resources to create the new table and initiate the restore process to copy the actual data.
- If data in the table is evenly distributed, then the restoration time is proportional to the largest single partition by item count.
- If the data is skewed, the restoration time might increase due to potential hot key throttling. For example, if your table’s primary key is using the month of the year for partitioning, and all your data is from the month of December, then you have skewed data.
- Restoring a table can be faster and more cost efficient if you exclude secondary indexes from being created.
- Restoration times for two different tables of different schemas and data can't be compared. This is because the restoration time for a table depends upon the data skewness on partition level.