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

DynamoDB Point-in-time recovery (PITR) restores a table to any second within the last 35 days, including the schema that existed at that timestamp. When a schema change such as adding or removing a Global Secondary Index is rolled back by restoring to an earlier point, the restored table reflects the previous schema, but all writes made after the restore timestamp are absent. The service does not provide an automatic rollback API, and it does not merge post-restore writes into the recovered schema, forcing a choice between reverting the schema and losing recent data.

Because restoring a large table can take minutes to hours and leaves the original table unavailable unless a temporary copy and swap strategy is used, teams need a predictable way to reconcile the restored schema with newer writes. Restored GSIs may also carry a backlog of pending index updates, which can throttle writes if traffic resumes immediately.

What is the recommended operational pattern for reverting a DynamoDB schema change with PITR while preserving writes that occurred after the restore point? Is there a supported mechanism to replay or merge those writes into the restored table without manual application logic? How should teams handle the GSI update backlog and throttling risk when swapping a restored table back into production?