Is there any benefit of having "timestamp" sort key, when I have "id" as partition key and I know it will always be unique?

Question

I have a DynamoDB table, that has partition key: id and sort key as number timestamp (it will always be there).

The id will always be unique. Does it even make sense to have timestamp as sort key in such scenario? (and just use simple id as simple primary key?)

Answer 1

As already mentioned in a comment, having a timestamp as the sort key when the hash key is already unique provides no value.

I'll also mention that having a unique hash key means that you'll be limited to GetItem or Scan (of the full table). Unless you create some GSI's

Maybe you'll always know the ID and thus GetItem is all you need.

However, consider your other access patterns. You might be best served by picking a different hash key and including ID as (part of?) the sort key.

Since you mention timestamp, I'll point you to the Best practices for handling time series data in DynamoDB ; which actually uses multiple tables with different provisioned WCU/RCU. Probably overkill for most people, and possibly out of date given the availability of On-Demand Dynamo DB.

Answer 2

The simple answer is that you do not need it, but by having it you are doing no wrong.

You cannot add a sort key after a table has already been created, so should your use-case expand over time, such as having multiple items related to the same ID or perhaps you take a single table design approach then you'll be glad you have a sort key on your table as it alleviates the requirement to migrate to a new table.