To those familiar with DynamoDB, I'm trying to make a table where items only have 2 entries. For example, . Most of the time I'll be searching the user_id with a facebook_id on hand.

Amazon's DynamoDB only provides the ability to search based on 2 keys, the primary key and the range key. I have 2 options; either making the user_id or the facebook_id the primary key. Primary and Range keys differ on the matching algorithm used.

I'm just curious which way is more efficient in this case? Searching with the primary key, or searching with the range key, or is there really no difference?

Could we add DynamoDB as a tag? As DynamoDB is fairly new, I'll not be surprised if no-one knows the answer.


Are you trying to determine if to query only using the hash OR only the range key? Unless I'm misunderstanding your question, you are not able to to perform a query with just the range keys. For example, if your range key was the date, you cannot query with just two dates, you MUST also specify the hash key. Remember when using both hash and range keys, the primary key IS both the hash and range, however the range can be optional.

With that said, I suggest specifying the facebook_id as the hash and your user_id as an attribute not the range. Use this if only your logic is using the facebook_id as a lookup id to your application specific user_id.


I realize that this is an old question, but I came across it when looking for something else. I believe things have changed since this question was asked, and now the way to do this is with a Global Secondary Index.

You can create the primary hash key with the user_id attribute, and then create a GSI using the facebook_id. Then, when you want to find a user by user_id, you query the table directly, and when you want to query by facebook_id, you query the index (you need to specify the index when you make the query).

The main table primary key (user_id, in this example) is always projected into the index, but if there were other columns in the document, you could choose to project them into the index as well. This will speed up reads, since the whole read can be made from the index (instead of a two-step read that has to hit the main table after the index), at the cost of increased storage.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.