It's ok to be explicit here and in PrimaryKey class, but we can consider making PrimaryKey an aggregate https://en.cppreference.com/w/cpp/language/aggregate_initialization. The consequences would be that here we could simply return {BackupItem::FIELD_USER_ID, BackupItem::FIELD_CREATED}.
The PrimaryKey can then be simply

struct PrimaryKey {
  const std::string partitionKey;
  std::unique_ptr<std::string> sortKey = nullptr;
};

What do you think about this idea?

We probably need to consider the whole primary key here, not only the partition

Not sure, maybe we should explicitly use userID column here instead of the partition key. We want to find an item for a user and the coincidence that this is also a partition key should be an implementation detail at this point

The same here. Do you think it makes sense to use user id column here explicitly?

See feedback in D3160... I'm concerned that with this database design, it may not be possible to efficiently look up a backup based on BACKUP_ID, which is a requirement of the current architecture design