Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 4 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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