User ID vs ID for primary key dynamoDB

Question

I have a table in which has a "userId" column (set as a partition key) and a "createdAt" column (set as the sort key) so they form up a composite primary key.

I also need to find the exact row in case I don't have the User ID available, so I made another column "id" and made it as a global secondary index.

In my case, should I make the "id" column the primary key and remove the "userId" as the partition key or will this remove the feature of what "Partitioning" actually does by the DynamoDB?

Similarly, If I need to delete a row from the table, should I send "createdAt" field from the front end to be able to find out the exact row? Does this make sense? Sending the "id" of the row seems more good to me to be able to delete the row.

OK, so generate a UUID or supply a unique ID, store it in an ID attribute with each item that is written and create a GSI for ID. You'll then be able to delete an item by querying the GSI for the related ID, retrieving the partition/sort keys and deleting the item. How your client/app knows which ID to delete is up to you. — jarmod

Seth Geoghegan Seth Geoghegan · Accepted Answer · 2021-08-09T22:13:50

You probably don't want to put a timestamp in your user primary keys. Why? You'd need to know the exact time the user was created to fetch a user, which is probably not what you want.

Consider using a partition key of USER#<user_id> and a sort key of something predictable, like A or METADATA or USER#<user_id>. This allows you to fetch/delete a user by their ID.

If you have access patterns around fetching users in order of account creation, you can create a GSI with the sort key set to the createdAt attribute.

User ID vs ID for primary key dynamoDB

1 Answers