Migrating Amplify's DynamoDB Data to Postgres: Why Lists Scan, Why Pages Come Back Empty, and How to Move It

Amplify list queries use DynamoDB scans, and DynamoDB applies filters after reading up to 1 MB, so a filtered page costs a full read and can return almost nothing. When the data is relational, Postgres is the better home. How to export, transform, keep the two in sync and switch.

Amplify's data docs say the list operation uses DynamoDB scan operations. DynamoDB's docs explain the consequence: a Scan reads up to 1 MB, then applies the filter, and Limit counts items before the filter. Read capacity is charged for everything read, matching or not.

So a screen that lists "my open orders" from a large table reads pages of other people's orders, keeps the few that match, and returns a nextToken for the client to try again. It works at launch. It gets slower and more expensive every month after.

DynamoDB or Postgres

Moving the data

1. Turn on point-in-time recovery and export each table to S3. Exports don't consume read capacity or affect the live table.

2. Write the transform as code and run it against the export: types, relationships Amplify stored as id fields, timestamps, and soft-deleted rows.

3. Load Postgres, then keep it current: replay DynamoDB Streams from the export time, or run incremental exports on a schedule if a few minutes of lag is acceptable during the overlap.

4. Compare counts and checksums per entity every day of the overlap. A migration is done when the numbers match without anyone looking.

5. Switch reads, then writes, screen by screen. Keep the stream running in reverse only if something still reads DynamoDB.