DynamoDB’s New Feature Now Supports Multi-Attribute Keys For GSIs

Here’s how to make the most of this new feature and some data modeling tips on it

Amazon DynamoDB has just released one of the most impactful updates in recent years: native support for multi-attribute composite keys in Global Secondary Indexes (GSIs).

For architects, serverless developers, and AWS engineers, this is a big deal.

Until now, you had to manually concatenate multiple values into synthetic keys.

e.g. user#123#region#eu#status#active

in order to support complex query patterns. This approach works, but it requires overhead, having to maintain multiple values in one key, and forces everything into a string type.

Now, you can define up to 4 attributes for the GSI partition key and up to 4 attributes for the sort key, using native attribute types directly. This results in cleaner data models, better type safety, and far more flexible querying.

Let’s break it down.

Real-World Example: Multi-Tenant CRM System

Imagine you’re building a CRM app where users belong to organizations, and you want to fetch customers based on:

• Organization ID
• Team ID
• Customer segment
• Recent activity date

Previously, you’d do something like:

GSI1PK: `ORG#${orgId}#TEAM#${teamId}`,
GSI1SK: `SEG#${segment}#TS#${timestamp}`

Now, using the new multi-attribute GSI:

PartitionKey:
  - orgId (S)
  - teamId (S)
  - segment (S)

SortKey:
  - lastInteraction (N)

Here’s an example query:

const { DynamoDBDocumentClient, QueryCommand } = require("@aws-sdk/lib-dynamodb");
const dynamo = DynamoDBDocumentClient.from(new DynamoDBClient({}));

const response = await dynamo.send(
  new QueryCommand({
    TableName: "crm",
    IndexName: "CustomerByOrgTeamSegment",
    KeyConditionExpression:
      "orgId = :org AND teamId = :team AND segment = :segment AND lastInteraction > :ts",
    ExpressionAttributeValues: {
      ":org": "org#A1",
      ":team": "marketing",
      ":segment": "enterprise",
      ":ts": 1700000000,
    },
  })
);

No string concatenation, no parsing, no ambiguity, and numeric comparison is now accurate.

Some Best Practices

Keep in mind the best practices haven’t changed much and these will always dictate the efficiency of your queries:

1. Design attribute order carefully

• Partition key attributes must all be provided in queries.
• Sort key conditions apply left to right: place your most selective sorting attribute last.

2. Keep attribute typing logical

• Use Numbers for timestamps or metrics.
• Use Strings for entities (e.g. orgId, teamId).

3. Avoid over-indexing

• Just because you can use 8 attributes doesn’t mean you should.
• Use this feature to solve concrete query patterns, not to store all item metadata.

4. Plan backward compatibility: If you’re currently using synthetic keys, consider introducing an additional GSI with multi-attribute keys rather than replacing immediately.

5. Use sparse indexes strategically: You can still omit attributes to avoid indexing unwanted items.

[embed]The 5 AWS Services You Need To Build 95% Of Apps You don’t need to know all 200+ AWS services to build most apps — just these 5.aws.plainenglish.io

Conclusion

This update brings DynamoDB closer to what many developers wished for: composable, type-safe keys without sacrificing performance.

For anyone building multi-tenant apps, complex analytics queries, or models with layered access patterns, this eliminates one of the most common workarounds in DynamoDB design.

It’s still a highly scalable NoSQL database at its core, but now with a lot more elegance in how you define your indexes.

👋 My name is Uriel Bitton and I’m committed to helping you master AWS, serverless and DynamoDB.

🚀 Build the database your business needs with DynamoDB — subscribe to my email newsletter Excelling With DynamoDB.

☕️ Need help with DynamoDB? Book a 1:1 with me here.

Thanks for reading and see you in the next one!

References

1. https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-dynamodb-multi-attribute-composite-keys-global-secondary-indexes/