Is it a good practice to add a range key to an AWS dynamo table even if there is no need in current specification?

Question

I am using AWS dynamodb for my project.

One can choose to use a simple key (partition key alone) or a composite key (partition key + range key) when creating a dynamo db table. But once it is created, the decision is baked in.

For example, if a table was created with a partition key alone, and I need to add a range key due to new business need, the only possible way is by dropping the table and then recreate it with a new key structure.

It will be a major hassle to recreate a table like this. After all if I want to use dynamodb, holding a lot of data will be the primary motive. It is impractical to recreate table to add a range key.

So, as a design question, does it make sense to:

Always add a range key to an AWS dynamo db table design, even though there is no such need at the time of requirement analysis, to future proof the table design.

The dummy range key can reuse the partition key value at the beginning. It is a minor innocence in coding, but it may offer more resilience in the future.

Is it a sound strategy?

Answer 1

No. This is a clear case of YAGNI - design the system for the requirements you have today and don't worry about what requirements may come along tomorrow, because you have no idea what they're going to be.

In particular for DynamoDB, you have to choose a type for your range key. Your solution of "copy the partition key" is going to add value only if your unknown future requirement:

1. Is something that can be modelled with a range key at all
2. Is something that can be modelled with a range key the same type as your current partition key.

More generally, this statement concerns me about your design:

if I want to use dynamodb, holding a lot of data will be the primary motive

DynamoDB is great for use cases which involve lots of accesses, each for a relatively small amount of data - e.g. shopping carts. It is most definitely not a good fit for general "lots of data" cases, most notably because your only option if you can't exactly identify the records you want via your keys (or secondary indexes) is to scan the whole table. DynamoDB is also expensive in terms of dollars per byte stored.