Should I really use one DynamoDB table for all data?

Question

The DynamoDB best practice documentation has this line:

You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.

It's the last line that confuses me the most.

Take an example photo storage application. Does this mean that I should store user accounts (account ID, password, email) and photos (owner ID, photo location, metadata) in the same table?

If so I assume the primary key should be the account/owner ID, and the sort key would be the type of object it is (e.g. account or photo).

Should I be using one table like this instead of two tables (one for accounts, one for photos)?

Answer 1

It is generally recommended to use as few tables as possible, and very often a single table unless you have a really good reason to use more than one. Chances are you won't have a good reason to use more than one - except for old habits.

It seems counter-intuitive if you are coming from a traditional database background (like me), but it is in fact best practice.

The primary key could become a combination of the 'row'/object type and another value, stored in a single field, i.e. 'account#12345' for an account object with unique id of 12345 and 'photo#67890' for a photo object with your id of 67890 -

If you are looking up an account by your id number, you would query with the account prefix, and if you were looking for a photo, you would add the 'photo' prefix. this is a very simple example - your design may vary.

The video recommended in the first comment on your question is excellent - watch it at 0.75 speed or slower, and watch it a few times.

Answer 2

The short answer is yes. But the way it would be designed would be highly specific to how your application interacts with the database.

I highly recommend that anyone still confused with how to design DynamoDB/NoSQL tables watches this video from re:Invent.