DynamoDB PITR schema rollback missing automatic merge for post-restore writes

Reconciling PITR Restores

There is no native AWS mechanism to automatically merge post-restore writes into a table recovered via Point-in-Time Recovery (PITR). Because PITR creates a entirely new table rather than performing an in-place rollback, any data written to the original table after the chosen restore timestamp is not captured in the restored instance.

Recommended Operational Pattern

To revert a schema change while preserving recent writes, you must implement a Stream-based Replay pattern. This requires DynamoDB Streams to be enabled on the source table before the restore process begins.

1. Restore: Use PITR to create a new table (e.g., Table_Restored) at the desired timestamp.
2. Capture: Enable a DynamoDB Stream on the original production table to capture all modifications occurring after the restore point.
3. Replay: Deploy a custom consumer (typically an AWS Lambda function) to read the stream shards and apply those changes to Table_Restored.
4. Swap: Once the stream is caught up and GSIs are backfilled, update your application configuration or DNS to point to the restored table.

Handling GSI Backlogs and Throttling

When a table is restored, Global Secondary Indexes (GSIs) are backfilled asynchronously. If you route production traffic to the restored table before this process completes, you risk severe write throttling because the backfill process consumes provisioned throughput.

• Verification: Monitor the PendingReplicationCount metric in Amazon CloudWatch for every GSI on the restored table.
• Cut-over Trigger: Do not swap production traffic until PendingReplicationCount reaches zero for all indexes.
• Capacity Buffering: Temporarily increase the Write Capacity Units (WCU) on the restored table during the replay and backfill phase to prevent the replay consumer from throttling the backfill process.

Implementation Assumptions

This pattern assumes the use of a Last-Writer-Wins conflict resolution strategy during the stream replay. If your application requires complex versioning, the replay logic must be modified to check item timestamps before applying PutItem or UpdateItem calls to avoid overwriting newer data with older state.

Diagnostic Requirement: Are you using On-Demand capacity or Provisioned capacity? If using Provisioned, the risk of throttling during GSI backfill is significantly higher and requires manual scaling before the swap.