Introduction

Yes, you can add a global secondary index, or GSI, to an existing DynamoDB table after the table has already been created. That is one of the major differences between a global secondary index and a local secondary index, because local secondary indexes must be defined when the table is created.

Adding a GSI is useful when a new access pattern appears and the original primary key no longer supports the queries you need.

What A GSI Changes

A global secondary index gives DynamoDB another key structure for querying the same table data. The index has its own partition key and optional sort key, and it can project some or all table attributes into the index.

That means you can support queries such as "find all orders by customer id" even if the base table was originally designed around an order id primary key.

Adding A GSI After Creation

You can add the index through the AWS console, AWS CLI, or an SDK. The table remains available while DynamoDB creates and backfills the new index in the background.

A CLI example looks like this:

1aws dynamodb update-table \
2  --table-name Orders \
3  --attribute-definitions \
4      AttributeName=customer_id,AttributeType=S \
5  --global-secondary-index-updates \
6      '[{"Create":{"IndexName":"customer-index","KeySchema":[{"AttributeName":"customer_id","KeyType":"HASH"}],"Projection":{"ProjectionType":"ALL"}}}]'

After the request is accepted, the index moves through a creation process and becomes queryable when the build finishes.

Operational Impact

Creating a GSI is not just a metadata change. DynamoDB has to backfill the index from existing table items, and future writes to the table must also update the index.

That means GSIs affect:

• write cost
• storage cost
• write throughput behavior
• eventual consistency expectations on index reads

So the technical answer is yes, but the operational answer is "yes, and you should plan for the extra cost and write activity."

Querying The New Index

Once the GSI is active, you query it by index name:

1import boto3
2
3client = boto3.resource("dynamodb")
4table = client.Table("Orders")
5
6response = table.query(
7    IndexName="customer-index",
8    KeyConditionExpression="customer_id = :cid",
9    ExpressionAttributeValues={":cid": "C123"},
10)
11
12print(response["Items"])

The exact query expression depends on your chosen key schema, but the important part is that the index is explicitly named during the query.

What You Cannot Do

You cannot add a local secondary index after table creation. That design decision often surprises people, so it is worth stating plainly: post-creation index expansion is available for GSIs, not LSIs.

That is one reason why DynamoDB table design and expected query patterns deserve careful thought up front, even though GSIs provide some flexibility later.

Common Pitfalls

The biggest mistake is adding a GSI without a real query pattern in mind. An index should exist to support a concrete access need, not as a vague future possibility.

Another pitfall is ignoring the extra write and storage cost. Every indexed write means more work for DynamoDB and more cost for the application.

A third issue is assuming GSI reads behave exactly like table reads in every consistency scenario. Indexes are commonly used with eventual consistency semantics, so timing-sensitive workflows should be designed accordingly.

Summary

• You can add a global secondary index to an existing DynamoDB table.
• DynamoDB builds and backfills the new index after the update request.
• GSIs enable new query patterns without recreating the whole table.
• They also increase storage and write cost.
• Local secondary indexes are different and must be defined at table creation time.