UUID as primary key in DynamoDB -- good or bad idea?

Question

In a new DynamoDB table, my use cases are already fulfilled by the following key schema design:

partition key: user_id
sort key: entity_id

Basically, access patterns are:

Get specific post by a specific user.
Get specific comment by a specific user.
List all posts by specific user.
List all comments by specific user.
List all entities (post or comment) by a specific user.

What benefits do I get if I use a more random ID as partition key instead and simply use GSIs for my access patterns above?

partition key: pseudo_random_id (This is going to be a UUID in reality. Please ignore that this is NOT a UUID in the illustration).
GSI:
- partition key: user_id
- sort key: entity_id

FYI, your example pseudo_random_id values are not UUIDs. The term UUID has a very specific standardized meaning. A UUID is a 128-bit value, presented to humans in canonical format as 32 hex characters grouped by 4 hyphen characters. Example: 403fc3f4-9bb9-11e9-a2a3-2a2ae2dbcce4. Please edit the title and body of your Question to make clear if you meant UUID or something else. — Basil Bourque

Matthew Pope Matthew Pope · Accepted Answer · 2019-07-01T05:06:45

You don’t need UUIDs or any pseudo-random ID.

It was once possible that you could have a hot partition if one user is particularly active, but hot partitions are basically a non-issue now because of DynamoDB’s adaptive capacity. Furthermore, you should probably be limiting how fast users can create comments/posts, which would prevent hot partitions even if adaptive capacity didn’t exist.

(Why should you limit the rate a user can post? You don’t want a malicious actor to be able to create a new post every few milliseconds—you should have some sort of rate limit as a protection against denial of service attacks.)

UUID as primary key in DynamoDB -- good or bad idea?

2 Answers