DynamoDB global table version mismatch

TL;DR — DynamoDB has two global-table versions: 2017.11.29 (Legacy) and 2019.11.21 (Current). Creating a legacy global table or adding a replica fails when the member tables don't meet the requirements — legacy replicas must be empty, share the same name, key schema, and matching GSIs, have DynamoDB Streams (new and old images) enabled, and use consistent write capacity — and pointing one version's APIs at the other version's tables fails outright. Align every replica's configuration (or upgrade to the Current version), then retry.

What it means

ValidationException: Cannot create a global table from a table with ...
ValidationException: ... replicas must have the same ... across all regions

The Legacy version (2017.11.29) stitches independently created regional tables into a named global table, so it demands that the member tables line up exactly. The Current version (2019.11.21) manages replication on the table itself — you add replicas with UpdateTable — and synchronizes TTL, auto scaling, GSI, and encryption-at-rest settings across replicas automatically. Version-mismatch errors appear when the tables you're combining disagree, or when tooling talks to the wrong version's API surface.

Why it happens

A replica table isn't empty — the legacy CreateGlobalTable/UpdateGlobalTable APIs require every member table to contain no data.
Name or key schema mismatch — all replicas must share the same table name and primary key.
Mismatched GSIs — global secondary indexes must match across replicas in name and in hash/sort key.
Streams off or wrong view type — each legacy replica needs DynamoDB Streams enabled with both the new and the old images of the item.
Inconsistent write capacity — AWS requires write capacity settings to be set consistently across replica tables and matching secondary indexes (auto scaling recommended, or equal replicated write capacity units).
Mixing the two versions — pointing the legacy APIs (DescribeGlobalTable, UpdateGlobalTable) at a Current-version table returns GlobalTableNotFoundException instead of working.
Outdated AWS CLI/SDK — a release that predates the 2019.11.21 model can't drive UpdateTable-based replica management.

How to fix it

Standardize the member tables across all regions — same name and key schema, matching GSIs, streams enabled with new + old images, and consistent write capacity/auto-scaling targets.
Check current state with DescribeTable per region (Current) or DescribeGlobalTableSettings (a Legacy-only API) and correct drift with UpdateTable or UpdateGlobalTableSettings respectively.
Upgrade Legacy → Current deliberately via the console's Update version flow — it needs the dynamodb:UpdateGlobalTableversion permission in every replica Region, and replicas keep serving reads and writes during the upgrade.
Update your AWS CLI/SDK to a recent release before managing Current-version replicas.
Add replicas to a compatible base table — Current-version replicas are added with UpdateTable (the table may already contain data, but the target Region must not already have a table with that name); legacy replicas must start empty.
Enable streams before legacy create. Each legacy replica needs DynamoDB Streams with new and old images — verify with DescribeTable in every Region.

Measure in DynoTable

Compare schema, GSIs, and stream settings across Regions before you create a global table — switch with ⌘P, open each replica with ⌘K, and expand the Indexes and Stream panels side by side.

Estimate replicated write cost with the pricing calculator. Configure each Region under Settings → Profiles with Test Connection. See Connect to AWS and Install.

Sources

DynamoDB global tables versions (verified 2026-07-13)
CreateGlobalTable — Amazon DynamoDB API Reference (verified 2026-07-13)

ResourceInUseException — a replica table/region is already in use.
ReplicaNotFoundException — a referenced replica region doesn't exist.
Learn: DynamoDB global tables

References

Last verified 2026-07-13 against the official AWS documentation linked above.